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I. REAL PARTY IN INTEREST 

The real party in interest for the above-identified patent application on appeal is Siemens 
Aktiengesellschaft, by virtue of an Assignment dated September 12, 2001 and recorded at the 
United States Patent and Trademark Office at reel 012241, frame 0293. 
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II. RELATED APPEALS AND INTERFERENCES 

Appellants' legal representative and the Assignee of the above-identified patent 
application do not know of any prior or pending appeals, interferences or judicial proceedings 
which may be related to, directly affect or be directly affected by or have a bearing on the 
Board's decision with respect to the above-identified Appeal. 
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III. STATUS OF CLAIMS 

Claims 1-25 are pending in the above-identified patent application. Claims 1-25 stand 
rejected. Therefore, Claims 1-25 are being appealed in this Brief. A copy of the appealed claims 
is included in the Claims Appendix. 
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IV. STATUS OF AMENDMENTS 

A Final Office Action was mailed on February 22, 2006. Appellants filed a Pre-Appeal 
Brief Conference Request on May 22, 2006. After reviewing the rejection, the pre-appeal 
conference could not agree to a resolution and forwarded the application to this Board via the 
decision dated August 1, 2006. A copy of the Final Office Action is attached as Exhibit A in the 
Evidence Appendix. 
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V. SUMMARY OF CLAIMED SUBJECT MATTER 

A summary of the invention by way of reference to specification and/or figures for each 
of the independent claims is provided as follows: 

Independent Claim 1 is directed to a telecommunication network that includes a central 
server (S) of an access or service provider, where the central server includes an interrogation part 
(3) for interrogating hardware and software configurations of a plurality of terminal devices 
([0025]). The server also includes a software transmitting part [0012, 0017] for loading software 
and/or data that is customized according to the detected hardware and software configuration one 
of the plurality of terminal devices [0029]. A plurality of terminal devices include a response 
transmitting part for transmitting a configuration code [0026, 0032] identifying the respective 
hardware and software configuration to the central server in response to an inquiry by the 
interrogation part. Each of the plurality of terminal devices also including a software receiving 
part for receiving and internally storing at least one of the transferred software and data, where 
the interrogation part and the response transmitting part interrogate the respective hardware and 
software configuration and to transmit the respective configuration code when the terminal 
device logs onto the telecommunication network, or when predetermined times or time intervals 
occur [001 1, 0033; FIG. 1]. Distributed control parts, which are distributed in both the central 
server and the plurality of terminal devices, implement an interactive control over the software 
transmitting part, and for the interactive specifying of a charging mode for at least one of 
downloaded software and downloaded data [0017, 0020, 0026-27]. 

Independent Claim 21 is directed to terminal device for use in a telecommunication 
network having a plurality of terminal devices of users, each having a predetermined hardware 
and software configuration, and a central server of an accessor service provider, where the 
terminal device includes a response transmitting part for transmitting a configuration code that 
identifies a currently implemented hardware and software configuration to the central server in 
response to an interrogation by the central server [0025-26, 0029, 0032]. Distributed control 
parts implement an interactive control of the downloading of software and/or data from the 
central server [0017, 0035]. A charging mode display part displays at least one available 
charging mode for one of offered and selected software and data, where a charging mode 
confirmation part specifies the charging mode [0031-32]. 
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Although specification citations are given in accordance with C.F.R. 1.192(c), these 
reference numerals and citations are merely examples of where support may be found in the 
specification for the terms used in this section of the Brief. There is no intention to suggest in 
any way that the terms of the claims are limited to the examples in the specification. As 
demonstrated by the reference numerals and citations, the claims are fully supported by the 
specification as required by law. However, it is improper tinder the law to read limitations from 
the specification into the claims. Pointing out specification support for the claim terminology as 
is done here to comply with rule 1.192(c) does not in any way limit the scope of the claims to 
those examples from which they find support. Nor does this exercise provide a mechanism for 
circumventing the law precluding reading limitations into the claims from the specification. In 
short, the reference numerals and specification citations are not to be construed as claim 
limitations or in any way used to limit the scope of the claims. 
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VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

1. Claims 1-4, 14, 21, 22 and 24 were rejected under 35 U.S.C. 103(a) as being unpatentable 
over Kobata (U.S. Patent No. 4,540,585) in view of Nakagawa (U.S. Patent 5,835,911); 

Claims 5-6 were rejected under 35 U.S.C. 103(a) as being unpatentable over Kobata 
(U.S. Patent No. 4,540,585) in view of Nakagawa (U.S. Patent 5,835,91 1), and further in 
view of Chen et al. (U.S. 5,797,016); 

Claims 7, 12, 13, and 23 were rejected under 35 U.S.C. 103(a) as being unpatentable over 
Kobata (U.S. Patent No. 4,540,585) in view of Nakagawa (U.S. Patent 5,835,91 1), and 
further in view of Valentine (U.S. 6,018,654); 

Claim 8 was rejected under 35 U.S.C. 103(a) as being unpatentable over Kobata (U.S. 
Patent No. 4,540,585) in view of Nakagawa (U.S. Patent 5,835,91 1), and further in view 
of Pepe et al. (U.S. Patent 5,742,668); 

Claims 9-1 1 and 25 were rejected under 35 U.S.C. 103(a) as being unpatentable over 
Kobata (U.S. Patent No. 4,540,585) in view of Nakagawa (U.S. Patent 5,835,911), and 
further in view of Shear (U.S. Patent 4,977,594); 

Claims 15 and 17 were rejected under 35 U.S.C. 103(a) as being unpatentable over 
Kobata (U.S. Patent No. 4,540,585) in view of Shah (U.S. Patent 6,029,065) and further 
in view of Nakagawa (U.S. Patent 5,835,91 1); 

Claims 19 and 20 were rejected under 35 U.S.C. 103(a) as being unpatentable over 
Kobata (U.S. Patent No. 4,540,585) in view of Shah (U.S. Patent 6,029,065) in view of 
Nakagawa (U.S. Patent 5,835,01 1) and further in view of Shear (U.S. Patent 4,977,594). 
A copy of Kobata, Nakagawa, Chen, Valentine, Pepe, Shear and Shah are attached 
herewith as Exhibits B, C D, E, F, G and H . respectively. 
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VII. ARGUMENT 

A. LEGAL STANDARDS 

1. Obviousness under 35 U.S.C. § 103 

The Federal Circuit has held that the legal determination of an obviousness rejection 

under 35 U.S.C. § 103 is: 

whether the claimed invention as a whole would have been 
obvious to a person of ordinary skill in the art at the time the 
invention was made... The foundational facts for the prima facie 
case of obviousness are: (1) the scope and content of the prior art; 
(2) the difference between the prior art and the claimed invention; 
and (3) the level of ordinary skill in the art. . .Moreover, objective 
indicia such as commercial success and long felt need are relevant 
to the determination of obviousness... Thus, each obviousness 
determination rests on its own facts. 

In reMayne, 41 U.S.P.Q. 2d 1451, 1453 (Fed. Cir. 1997). 

In making this determination, the Patent Office has the initial burden of proving a prima 
facie case of obviousness. In re Rijckaert, 9 F.3d 1531, 1532, 28 U.S.P.Q. 2d 1955, 1956 (Fed. 
Cir. 1993). This burden may only be overcome "by showing some objective teaching in the prior 
art or that knowledge generally available to one of ordinary skill in the art would lead that 
individual to combine the relevant teachings." In re Fine, 837 F.2d 1071, 1074, 5 U.S.P.Q. 2d 
1596, 1598 (Fed. Cir. 1988). "If the examination at the initial stage does not produce a prima 
facie case of unpatentability, then without more the applicant is entitled to grant of the patent." 
In re Oetiker, 24 U.S.P.Q. 2d 1443, 1444 (Fed. Cir. 1992). 

To establish a prima facie case of obviousness, three basic criteria must be met. First, 
there must be some suggestion or motivation, either in the reference or references themselves or 
in the knowledge generally available to one of ordinary skill in the art, to modify the reference or 
to combine reference teachings. In re Fine, 837 F.2d 1071, 5, U.S.P.Q.2d 1596 (Fed. Cir. 1988). 
Second there must be a reasonable expectation of success. In re Merck & Co., Inc., 800 F.2d 
1091, 231 U.S.P.Q. 375 (Fed. Cir. 1986) Finally, all of the claim limitations must be taught or 
suggested by the prior art. In re Royka, 490 F.2d 981, 180 U.S.P.Q., 580 (CCPA 1974). 

Further, the Federal Circuit has held that it is "impermissible to use the claimed invention 
as an instruction manual or 'template' to piece together the teachings of the prior art so that the 
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claimed invention is rendered obvious." In re Fritch, 23 U.S.P.Q.2d 1780, 1784 (Fed. Cir. 
1992). "One cannot use hindsight reconstruction to pick and choose among isolated disclosures 
in the prior art to deprecate the claimed invention" In re Fine, 837 F.2d 1071 (Fed. Cir. 1988). 

Moreover, the Federal Circuit has held that "obvious to try" is not the proper standard 
under 35 U.S.C. §103. Ex parte Goldgaber, 41 U.S.P.Q.2d 1172, 1177 (Fed. Cir. 1996). "An- 
obvious-to-try situation exists when a general disclosure may pique the scientist curiosity, such 
that further investigation might be done as a result of the disclosure, but the disclosure itself does 
not contain a sufficient teaching of how to obtain the desired result, or that the claimed result 
would be obtained if certain directions were pursued." In re Eli Lilly and Co., 14 U.S.P.Q.2d 
1741, 1743 (Fed. Cir. 1990). 

Of course, references must be considered as a whole and those portions teaching against 
or away from the claimed invention must be considered. Bausch & Lomb, Inc. v. Barnes- 
Hind/Hydrocurve Inc., 796 F.2d 443 (Fed. Cir. 1986). "A prior art reference may be considered 
to teach away when a person of ordinary skill, upon reading the reference would be discouraged 
from following the path set out in the reference, or would be led in a direction divergent from the 
path that was taken by the Applicant." Monarch Knitting Machinery Corp. v. Fukuhara 
Industrial Trading Co., Ltd., 139 F.3d 1009 (Fed. Cir. 1998), quoting, In re Gurley, 27 F.3d 551 
(Fed. Cir. 1994). 

B. THE CLAIMED INVENTION - CLAIM 1 

Independent Claim 1 recites, in part, a central server having an interrogation part for 
interrogating hardware and software configurations of a plurality of terminal devices and a 
plurality of terminal devices including a response transmitting part for transmitting a 
configuration code identifying the respective hardware and software configuration to the central 
server in response to an inquiry by the interrogation part. The interrogation part and the response 
transmitting part interrogate the respective hardware and software configuration and transmit the 
respective configuration code when at least one of the terminal device logs onto the 
telecommunication network, predetermined times occur, and predetermined time intervals occur. 
Distributed control parts are distributed in both the central server and the plurality of terminal 
devices, where the distributed control parts implement an interactive control over the software 
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transmitting part, and being constructed for the interactive specifying of a charging mode for at 
least one of downloaded software and downloaded data. 
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C. THE REJECTION OF CLAIM 1 UNDER 35 U.S.C. SI 03(A) TO KOBATA AND 
NAKAGAWA SHOULD BE REVERSED BECAUSE THE PATENT OFFICE HAS NOT 
ESTABLISHED A PRIMA FACIE CASE OF OBVIOUSNESS 

1- One having ordinary skill in the art would not be motivated to combine Kobata 
with Nakaeawa in the manner suggested in the Final Office Action to arrive at the 
present claims 

Appellants respectfully submit that the examiner has not taken into consideration the 
teachings as a whole in the cited prior art, and has further engaged in impermissible hindsight in 
formulating this rejection. As this Board is aware, the Federal Circuit has held that it is 
"impermissible to use the claimed invention as an instruction manual or 'template' to piece 
together the teachings of the prior art so that the claimed invention is rendered obvious." In re 
Fritch, 23 U.S.P.Q.2d 1780, 1784 (Fed. Cir. 1992). Indeed, references must be considered as a 
whole and those portions teaching against or away from the claimed invention must be 
considered . Bausch & Lomb, Inc. v. Barnes-Hind/Hydrocurve Inc., 796 F.2d 443 (Fed. Cir. 
1986). 

The entire disclosure of Kobata is directed to a "market delivery system," which is 
essentially advertisement delivery software that delivers advertisements or other "targeted" data 
from a server to users based on information and demographics collected from those users (col. 4, 
lines 22-25). Kobata discloses a system where software is first provided to each user in the 
network, and each user must execute - and permit - the software to transmit information about 
their computers and/or their software to the provider 10 (col. 3, lines 52-60; col. 4, lines 43-56; 
see claim 1: "when the client system executes the software"). The provider then receives an 
aggregate of information regarding various users' hardware and software physically residing on 
their computers (col. 4, line 57 - col. 5, line 5). Having this information, the provider can then 
tailor advertisements directed to users, and send advertisements that would be optimized by the 
software residing on a user's computer (e.g., PDF vs. MPEG), as well as the hardware residing 
therein (e.g., sound cards, video cards) (see col. 5, lines 1-5, 18-21). The configuration in 
Kobata is clearly disclosed as a "push" system, where, once a user has subscribed to the 
advertising service and the information from the users is initially received, the advertisements 
will begin to flow to the users from the server without further interaction (col. 5, lines 6-18, 33- 
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37). Like most every "push" system, such transmissions are transparent to the user, and are 
intended to be used with minimal interaction (col. 4, lines 43-49). 

Along a completely different line of software networking, Nakagawa teaches a system 
and method where an application program on a user's computer detects when software subject to 
maintenance is activated and transmits an inquiry over the network to the software vendor's 
computer for information on the current version of the software. The server program compares 
data in the inquiry with data relating to the latest version of the software and returns update 
instruction information and updated software if appropriate (see Abstract). Thus, while the 
software and hardware information concerning a user's computer is initially sent to the software 
provider, the subsequent updates are premised only upon the software version residing on a 
user's computer (col. 1, lines 13-19; col. 8, lines 26-36. Nakagawa further teaches an "access 
qualification level" for customers (col. 67, lines 50-60) where customers are offered various 
functionalities, based on their qualification level. Each qualification level assigned by the seller 
to the software allows users, depending on their qualification, to access different software at 
different levels of access (payment type, time of payment, etc. - col. 7, lines 39-48). 

It is apparent to Applicant that there is no teaching suggestion or motivation for one 
having ordinary skill in the art to combine Kobata with Nakagawa. As discussed above, Kobata 
is a system in which advertisements are targeted to users that choose to volunteer their PC 
hardware and software information so that an optimal advertising campaign can be formulated 
for them by advertisers - no software is being "updated". Furthermore, the "push" configuration 
makes it so that users transparently receive advertisements. Applicant submits Kobata teaches 
away from the presently claimed features, and further teaches away from Nakagawa. It is not 
understood why an interactive control would be implemented in Kobata to specify a "charging 
mode" mode for the downloaded advertisements. If the proposed modification would render the 
prior art invention being modified unsatisfactory for its intended purpose, then there is no 
suggestion or motivation to make the proposed modification. In re Gordon, 733 F.2d 900, 221 
USPQ 1125 (Fed. Cir. 1984). To suggest that users in Kobata would interactively pay the 
advertiser to receive advertisements misinterprets the teaching in the reference and of "push" 
systems in general, and runs contrary to common sense. Also, the access qualification in 
Nakagawa goes to upgrading and purchasing software on a networked user system so that buyers 
and sellers may effectively negotiate these transactions. In Kobata, there is no software to 
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"upgrade," but only content that is provided to the users (col. 4, lines 22-25, 34-42). Similarly, it 
is not understood how incorporating the access levels of Nakagawa, which restricts user access 
to software, would be feasible in the advertising-model system of Kobata. Again, it wouldn't 
make sense to have advertisers create restrictions to their own advertisements on putative 
consumers. Because of at least these differences, Appellants respectfully submit that the 
Examiner has failed to provide a sufficient basis or motivation for combining the cited 
references. Consequently, in view of the portions of the cited references teaching away each 
other and from the present claims, one having ordinary skill in the art would not be motivated to 
modify or combine the cited references to arrive at the present claims. 

2. Kobata and Nakasawa, alone or in combination, fail to disclose or suggest all of 
the recited feature of claim 1 

Appellants respectfully submit that, even if combinable, the cited references do not 
disclose or suggest all of the claimed elements. For example, claim 1 recites "a central server 
having an interrogation part for interrogating hardware and software configurations of a plurality 
of terminal devices" where the terminal devices have "a response transmitting part for 
transmitting a configuration code identifying the respective hardware and software configuration 
to the central server in response to an inquiry by the interrogation part." 

Kobata discloses a client software package (64) that is first installed at a client's 
computer. The client then subsequently executes the software, whereupon the software transmits 
the client's software/hardware configuration (col. 4, lines 57-67). Thus, the corresponding data 
transfer is initiated solely on the client's side (col. 3, lines 6-9, 52-60), and cannot be considered 
a result of an "interrogation," either in the technical or conventional sense. There is no 
"response" being initiated by the client. Moreover, the response is not in the form of a 
configuration code, as recited in the present claims. 

Nakagawa discloses a client sending information about a software version in response to 
a query, however, Nakagawa does not disclose a software and hardware configuration being 
transmitted, and also does not disclose a configuration code. 
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Also, claim 1 recites that the interrogation part and the response transmitting part 
interrogate the hardware and software configuration and transmit the respective configuration 
code when at least one of the terminal device (1) logs onto the telecommunication network, (2) 
predetermined times occur, and (3) predetermined time intervals occur. Kobata clearly fails to 
teach this configuration. 

Moreover, claim 1 recites distributed control parts, which are distributed in both the 
central server and the plurality of terminal devices, where the distributed control parts implement 
an interactive control over the software transmitting part, and specifying a charging mode for at 
least one of downloaded software and downloaded data. As discussed above, Kobata does not 
have any control parts distributed to implement interactive control for charging modes. 
Regarding Nakagawa, the reference teaches that the client's program directs a query to a 
software provider's server over a network (col. 1, lines 13-19; col. 8, lines 26-36). The "access 
qualification level" disclosed in Nakagawa only refers to control being implemented on the 
server side only (col. 67, lines 50-60). In other words, the access qualification levels in 
Nakagawa are a indicator of user rights that are defined by the seller on the server, as opposed to 
the server and the terminal devices - interactive control of the software transmission is controlled 
on the server side exclusively (see also col. 67, lines 39-48). 

As shown above, the cited references fail to disclose or suggest unique aspects of the 
present claims. Though one may argue that each piece is an independent element, each element 
is necessary and makes this inventive aspect unique. Consequently, the above-cited references 
fail to disclose or suggest while teaching away from the above unique aspects of the present 
claims. As a result of the above discussion, Appellants have met the burden of proof to show 
that Kobata and Nakagawa fail to render obvious the present claims. Appellants respectfully 
submit that the Examiner has improperly applied hindsight reasoning by selectively piecing 
together teachings of each of the references in an attempt to recreate what the claimed invention 
discloses. As the Federal Circuit explained, one cannot use "hindsight reconstruction to pick and 
choose among isolated disclosures in the prior art" to re-create the claimed invention. In re Fine, 
5 U.S.P.Q. 2d 1596 (Fed. Cir. 1988). Further, it is "impermissible to use the claimed invention 
as an instruction manual or 'template' to piece together the teachings of the prior art so that the 
claimed invention is rendered obvious." In re Fritch, 23 U.S.P.Q.2d 1780, 1784 (Fed. Cir. 
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1992). Accordingly, Appellants respectfully submit that Claims 1-14 are novel, nonobvious and 
distinguishable from the cited references and are in condition for allowance. 

D. THE REJECTION OF CLAIM 15 UNDER 35 U.S.C. SI 03(A) TO KOBATA. SHAH 
AND NAKAGAWA SHOULD BE REVERSED BECAUSE THE PATENT OFFICE 
HAS NOT ESTABLISHED A PRIMA FACIE CASE OF OBVIOUSNESS 

1. One having ordinary skill in the art would not be motivated to combine Kobata 
with Shah and Nakasawa in the manner suggested in the Final Office Action to 
arrive at the present claims 

For the same reasons recited above in connection with claim 1, there is no teaching, 
suggestion or motivation for one having ordinary skill in the art to combine these reference in the 
manner suggested in the Office Action. With regard to Shah, an interactive menu is provided for 
users that wish to accept or reject features available for a base station in a mobile 
telecommunication network (col. 9, lines 54-61). However, the Office Action doesn't reconcile 
how the signaling and network considerations for an interactive menu on the wireless network of 
Shah (i.e., paging channel/access channel) would be incorporated into the line-based system of 
Kobata. Under Shah, when a mobile user visits a network, registration procedures are used to 
enable the visited network to identify the mobile unit network connection and paging purposes, 
and the mobile station's home network, for billing purposes. Once registered, the base station 
will download information to the mobile station which will notify the mobile station of which 
network features are available and how they may be accessed in the local network (col. 3, lines 
31-40). However none of the system requirements of Shah - i.e., home location registers, base 
stations, mobile registration, etc. - is remotely applicable to the teaching of Kobata. 
Furthermore, as in Nakagawa, it is not explained how or why an interactive menu would be 
needed for the "push" system of Kobata. Again, Appellant respectfully submits this rejection, as 
in claim 1, was formulated through the use of impermissible hindsight, and without considering 
each reference as a whole when applying it to the presently claimed features. 
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2. Kobata, Shah and Nakasawa, alone or in combination, fail to disclose or suggest 
all of the recited feature of claim 15 

For the same reasons recited above in connection with claim 1, Kobata, Shah and 
Nakagawa fail to teach or suggest the recited features of claim 15. Accordingly, Appellants have 
met the burden of proof to show that Kobata, Shah and Nakagawa fail to render obvious the 
present claims. Appellants respectfully submit that the Examiner has also improperly applied 
hindsight reasoning by selectively piecing together teachings of each of the references in an 
attempt to recreate what the claimed invention discloses. As such, Appellants respectfully 
submit that Claims 15-25 are novel, nonobvious and distinguishable from the cited references 
and are in condition for allowance. 
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VIII. CONCLUSION 



Appellants respectfully submit that the Patent Office has failed to establish a prima facie 
case of obviousness under 35 U.S.C. §103(a) with respect to the rejections of Claims 1-25. 
Accordingly, Appellants respectfully submit that the obviousness rejections are erroneous in law 
and in fact and should therefore be reversed by this Board. The Director is authorized to charge 
any additional fees which may be required, or to credit any overpayment to Deposit Account No. 
02-1818. If such a withdrawal is made, please indicate the Attorney Docket No. 1 12740-257 on 
the account statement. 



Respectfully submitted, 



BELL, BOYD & LLOYD LLC 




Patricia Kane Schmidt 
Reg. No. 46,446 
Customer No. 29177 



Dated: September 1, 2006 
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CLAIMS APPENDIX 

PENDING CLAIMS ON APPEAL OF 
U.S. PATENT APPLICATION SERIAL NO. 09/899,435 

Claim 1 . A telecommunication network, comprising: 

a central server of an access or service provider, the central server having an interrogation 
part for interrogating hardware and software configurations of a plurality of terminal devices and 
a software transmitting part for loading at least one of software and data that is customized to the 
respectively detected hardware and software configuration onto one of the plurality of terminal 
devices; 

a plurality of terminal devices, each with a predetermined hardware and software 
configuration, each of the plurality of terminal devices including a response transmitting part for 
transmitting a configuration code identifying the respective hardware and software configuration 
to the central server in response to an inquiry by the interrogation part, each of the plurality of 
terminal devices also including a software receiving part for receiving and internally storing at 
least one of the transferred software and data, the interrogation part and the response transmitting 
part being designed to interrogate the respective hardware and software configuration and to 
transmit the respective configuration code when at least one of the terminal device logs onto the 
telecommunication network, predetermined times occur, and predetermined time intervals occur; 
and 

distributed control parts, which are distributed in both the central server and the plurality 
of terminal devices, the distributed control parts implementing an interactive control over the 
software transmitting part, and being constructed for the interactive specifying of a charging 
mode for at least one of downloaded software and downloaded data. 
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Claim 2. A telecommunications network as claimed in claim 1 , further comprising: 
an offer memory in the central server to which the distributed control parts are connected, the 
offer memory being addressable via the configuration code and having a plurality of memory 
areas, in each of the memory areas at least one of a software and a data offer which is tuned to a 
separate hardware and software configuration is listed; and 

wherein the distributed control parts include an offer transmitting part in the central 
server, the offer transmitting part for transferring contents of the respectively addressed offer 
memory area to the respective terminal device that has transmitted a configuration code, a 
transmission initiation unit in the central server, the transmission initiation unit for activating the 
transmitted part for loading at least one of software and data from at least one of the tuned 
software and the data offer, an offer display part in each of the plurality of terminal devices for 
displaying the memory contents of the respectively addressed offer memory area, and a 
requesting part in each of the plurality of terminal devices for selecting offered software and data 
for loading onto the terminal device, which send a request signal for at least one of desired 
software and data and a reject signal for unwanted software and data to the transmission 
initiation unit of the central server. 

Claim 3. A telecommunication network as claimed in claim 2, wherein the central 
server further includes a reject signal storage area for terminal-device-specific storage of reject 
signals in association with the transmitted software and data offers, such that the reject signal 
storage area is allocated to the offer memory on an output side as filter so that software and data 
offers which are quit via a reject signal are not repeated to a same user. 
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Claim 4. A telecommunication network as claimed in claim 3, further comprising: 
a charging mode memory in the central server to which the distributed control parts are 
connected, the charging mode memory being allocated to the offer memory and having at least 
one charging mode stored for at least one of each software offer and each data offer; and 

wherein the distributed control parts include a charging mode transmitting part in the 
central server connected to the charging mode memory for responding to the reception of one of 
a configuration code and a request signal, a charging mode display part in each of the plurality of 
terminal devices for displaying the at least one charging mode for at least one of the offered and 
the selected software and the offered and the selected data, and a charging mode confirmation 
part in each of the plurality of terminal devices for specifying the charging mode. 

Claim 5. A telecommunication network as claimed in claim 1 , wherein the central 
server further includes a terminal device operating data memory with a plurality of memory areas 
for the terminal-device-specific data storage of at least one of software and data that are 
implemented in the plurality of terminal devices, and operating data receiving and transmitting 
parts connected to the terminal device operating data memory for transferring the software and 
data from and to the plurality of terminal devices, and wherein each of the plurality of terminal 
devices further includes additional operating data transmitting and receiving parts for 
transferring the software and data to and from the central server. 

Claim 6. A telecommunication network as claimed in claim 5, wherein the 
operating data receiving and transmitting parts of both the central server and the plurality of 
terminal devices are so connected to the distributed control parts for implementing the interactive 
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control that the data storage in the central server occurs only upon the selection of a 
corresponding offer by a user of the terminal device. 

Claim 7. A telecommunication network as claimed in claim 1 , wherein the 
distributed control parts are formed as network-specific signaling parts on the basis of at least 
one of SIM cards, firmware, and applets/scripts. 

Claim 8. A telecommunication network as claimed in claim 1 , wherein the central 
server acts as an intermediate station in the loading of the software and the data onto a first of the 
plurality of terminal devices by one of a second of the plurality of terminal devices in the 
telecommunication network and a data terminal device in a data network which is linked to the 
telecommunication network. 

Claim 9. A telecommunication network as claimed in claim 1 , wherein the central 
server further includes a validation storage unit for storing at least one of validity data and 
authorization data in association with predetermined configuration codes as well as a comparison 
unit that is connected to the storage unit which compares the configuration codes that are 
transmitted by the plurality of terminal devices to stored configuration codes for the purpose of 
determining at least one of the validity of software stocks and data stocks and the usage 
authorization of a respective user. 

Claim 10. A telecommunication network as claimed in claim 9, wherein the software 
stocks and the data stocks that are one of implemented in the plurality of terminal devices and 
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downloaded into the plurality of terminal devices include application counter elements, the 
central server further including an arithmetic evaluation unit for evaluating the counter statuses 
of the application counter elements at one of predetermined times, time intervals, and times when 
the relevant terminal device logs onto the telecommunication network, for the purpose of 
achieving a use-based charging mode. 

Claim 11. A telecommunication network as claimed in claim 10, wherein the central 
server includes an auxiliary information transmission unit which is connected to at least one of 
the comparison unit and the arithmetic evaluation unit for transmitting messages to the respective 
terminal device relating to at least one of the validity of implemented software, the usage 
authorization, and the application counter status for the respective user, the plurality of terminal 
devices including auxiliary information reception and display units for receiving and displaying 
the messages. 

Claim 12. A telecommunication network as claimed in claim 1 , wherein the software 
that can be downloaded onto the plurality of terminal devices includes at least one of software 
components and data for implementing non-network-bound auxiliary functions of the plurality of 
terminal devices. 

Claim 13. A telecommunication network as claimed in claim 1, wherein the software 
and data that can be downloaded onto the plurality of terminal devices includes software 
components and data for implementing auxiliary services that are available in one of the 
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telecommunication network and a data network that is connected to the telecommunication 
network. 

Claim 14. A telecommunication network as claimed in claim 1, wherein the software 
and data that can be downloaded onto the plurality of terminal devices include update software 
and update data for updating software and data stocks that are stored in the plurality of terminal 
devices. 

Claim 15. A method of operating a telecommunication network having a plurality of 
terminal devices of users, each with a predetermined hardware and software configuration, and a 
central server of an access or service provider, the method comprising the steps of: 

interrogating the current hardware and software configurations of one of the plurality of 
terminal devices in an interrogation step at one of a time during logon onto the 
telecommunication network, predetermined times, and time intervals; 

transmitting, in a transmission step, the current hardware and software configuration of 
the respective terminal device to the central server; 

setting up in the central server and transmitting to the respective terminal device, based 
on the respectively transmitted hardware and software configuration, offer information for a user 
of a respective terminal device; 

displaying, in the context of an interactive menu in the respective terminal device, the 
offer information together with one of a select and a reject request, one of a request and a reject 
signal of the user which is generated by the user being registered; 
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transmitting, together with the offer information, charging mode signals to the respective 
terminal device and displaying the charging mode signals in the context of the interactive menu 
for selection by the user, and registering a charging mode in the central server in response to a 
selection made by the user; and 

downloading onto the respective terminal device by the central server, in response to the 
registered one of the request and the reject signals, at least one of software and data that are 
suitable for the respective terminal device and that are not already present at the respective 
terminal device. 

Claim 16. A method of operating a telecommunication network as claimed in claim 
15, the method further comprising the step of: transferring to the central server, when one of the 
plurality of terminal devices log onto the telecommunication network, at predetermined times, 
and at time intervals, software and data that is implemented in the plurality of terminal devices 
for the purpose of data storage, and transferring the software and data by the central server back 
to the plurality of terminal devices again upon the occurrence of a predetermined condition. 

Claim 17. A method of operating a telecommunication network as claimed in claim 
15, the method further comprising the steps of: storing at least one of the reject signals and the 
request signals in the central server for each individual terminal device; and generating 
subsequent offer information using the at least one of the stored reject signals and the stored 
request signals as a filter. 
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Claim 18. A method of operating a telecommunication network as claimed in claim 
15, the method further comprising the step of: using the central server as an intermediate station 
in the loading of software and data onto a first of the plurality of terminal devices by one of a 
second of the plurality of terminal devices in the telecommunication network and a data terminal 
device in a data network that is linked to the telecommunication network. 

Claim 19. A method of operating a telecommunication network as claimed in claim 
15, the method further comprising the steps of: storing at least one of validity data and 
authorization data in the central server in association with predetermined configuration codes; 
comparing the data to configuration codes that are transmitted by the plurality of terminal 
devices; and outputting to the plurality of terminal devices, as a result of the comparison, data 
relating to at least one of the validity of software and data stocks that are stored in the plurality of 
terminal devices and the usage authorization of the respective user. 

Claim 20. A method of operating a telecommunication network as claimed in claim 
15, the method further comprising the step of: evaluating in the central server, when at least one 
of a terminal device logs on, predetermined times occur, and time intervals occur, counter 
statuses of application counter elements of the software and data stocks that are implemented in 
the plurality of terminal devices for the purpose of performing a use-based charging, an 
evaluation result being transmitted to the plurality of terminal devices. 

Claim 21 . A terminal device for use in a telecommunication network having a 
plurality of terminal devices of users, each with a predetermined hardware and software 
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configuration, and a central server of an accessor service provider, the terminal device 
comprising: a response transmitting part for transmitting a configuration code that identifies a 
currently implemented hardware and software configuration to the central server in response to 
an interrogation by the central server; distributed control parts for implementing an interactive 
control of the downloading of at least one of software and data from the central server; a 
charging mode display part for displaying at least one available charging mode for one of offered 
and selected software and data; and a charging mode confirmation part for specifying the 
charging mode. 

Claim 22. A terminal device for use in a telecommunication network as claimed in 
claim 21, wherein the distributed control parts include an offer display part for displaying offer 
information that is transmitted by the central server and a requesting part for selecting at least 
one of software and data that is offered for downloading for the purpose of outputting at least 
one of a request signal and reject signal to the central server. 

Claim 23. A terminal device for use in a telecommunication network as claimed in 
claim 21, wherein the distributed control parts include signaling parts based on at least one of 
SIM cards, firmware, and applets/scripts. 

Claim 24. A terminal device for use in a telecommunication network as claimed in 
claim 21, further comprising: operating data transmitting and receiving parts for transferring at 
least one of software and data to and from the central server. 
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Claim 25. A terminal device for use in a telecommunication network as claimed in 
claim 21, further comprising: an auxiliary information reception and display unit for receiving 
and displaying messages that are transmitted on the central server side relating to at least one of 
the validity of software and data that are implemented in the terminal device, the usage 
authorization, and a use-based charge status. 
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DETAILED ACTION 

This Office Action is in response to an Amendment filed November 25, 2005. Claims 1-25 are 
currently pending. Any rejection not set forth below has been overcome by the current Amendment. 

Information Disclosure Statement 

1 . The Examine acknowledges the corrected reference number. 

Claim Rejections ■ 35 USC § 103 

2. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all obviousness 
rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 1 02 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains 
Patentability shall not be negatived by the manner in which the invention was made. 

3. Claims 1-4,14,21,22,24 rejected under 35 U.S.C. 103(a) as being unpatentable overKobata (US 
6,058,418), and further in view of Nakagawa et al. (US 5,838,91 1), herein referred to as Nakagawa. 

As per claims 1,21, Kobata discloses a telecommunication network, as claimed, comprising: 
central server of an access or service provider, the central server having an 
interrogation part for interrogating hardware and software configurations of a plurality of terminal 
devices and a software transmitting part for loading at least one of software and data that is customized 
to the respectively detected hardware and software configuration onto one of the plurality of terminal 
devices (see Fig. 1, Infrastructure Data and columns 4 and 5, lines 57-67 and 1-18); 

a plurality of terminal devices, each with a predetermined hardware and software configuration, 
each of the plurality of terminal devices including a response transmitting part for transmitting a 
configuration code identifying the respective hardware and software configuration to the central server in 
response to an inquiry by the interrogation part (see Fig. 1, Infrastructure Data with Serial No. and column 

4. lines 57-67), each of the plurality of terminal devices also including a software receiving part for 
receiving and internally storing at least one of the transferred software and data (see column 5, lines 1- 
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18), the interrogation part and the response transmitting part being designed to interrogate the respective 
hardware and software configuration and to transmit the respective configuration code when at least one 
of the terminal device logs onto the telecommunication network, predetermined times occur, and 
predetermined time intervals occur (see column 4, lines 57-67); and 

distributed control parts, which are distributed in both the central server and the plurality of 
terminal devices, the distributed control parts implementing an interactive control over the software 
transmitting part. 

Although the system disclosed by Kobata shows substantial features of the claimed invention 
(discussed above), it fails to disclose distributed control parts implementing an interactive control over the 
software transmitting part, and being constructed for the interactive specifying of a charging mode for at 
least one of downloaded software and downloaded data. 

Nonetheless, these features are well known in the art and would have been an obvious 
modification of the system disclosed by Kobata, as evidenced by Nakagawa et al. 

In an analogous art, Nakagawa discloses a software distributing system for updating a client with 
current software (see Abstract) and further showing an interactive control over transmitting software (see 
column 67, lines 50-60), and interactively specifying a charging mode for at least one of downloaded 
software and downloaded data (see column 68, lines 17-29). 

Given the teaching of Nakagawa, a person having ordinary skill in the art would have readily 
recognized the desirability and advantages of modifying Kobata by employing interactive control and a 
charging mode, such as disclosed by Nakagawa, in order to allow the user to choose certain programs 
they want and different methods of payment that may suit their needs. 

As per claim 2, Kobata in view of Nakagawa further disclose an offer memory in the central server 
to which the distributed control parts are connected, the offer memory being addressable via the 
configuration code and having a plurality of memory areas, in each of the memory areas at least one of a 
software and a data offer which is tuned to a separate hardware and software configuration is listed (see 
Kobata Fig. 5); and 
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wherein the distributed control parts include an offer transmitting part in the central server, the 
offer transmitting part for transferring contents of the respectively addressed offer memory area to the 
respective terminal device that has transmitted a configuration code, a transmission initiation unit in the 
central server, the transmission initiation unit for activating the transmitting part for loading at least one of 
software and data from at least one of the tuned software and the data offer (see Kobata Fig. 5 [112]), an 
offer display part in each of the plurality of terminal devices for displaying the memory contents of the 
respectively addressed offer memory area, and a requesting part in each of the plurality of terminal 
devices for selecting offered software and data for loading onto the terminal device (see Kobata column 
5, lines 41-44), which send a request signal for at least one of desired software and data and a reject 
signal for unwanted software and data to the transmission initiation unit of the central server (see Kobata 
column 5, lines 41-44, where accepting certain version implies an accept signal for the version wanted 
and a reject signal for the version unwanted). 

As per claim 3, although Kobata in view of Nakagawa discloses substantial features of the 
claimed invention (discussed above), it fails to directly disclose a filtering method based on previously 
rejected software by the terminal device. However, it would have been obvious to a person having 
ordinary skill in the art to stop offering software, which the terminal device has rejected. The desirability 
and advantages of having such a filtering means would be for the convenience of the user since the user 
would not have to continually decline the same software they do not want, analogous to a software 
system for allowing a user to stop checking for software updates by checking a box. 

As per claim 4, Kobata in view of Nakagawa further disclose a charging mode memory in the 
central server to which the distributed control parts are connected, the charging mode memory being 
allocated to the offer memory and having at least one charging mode stored for at least one of each 
offered software item (see Nakagawa column 27, lines 19-26); and 

wherein the distributed control parts include a charging mode transmitting part in the central 
server connected to the charging mode memory for responding to the reception of the one of a 
configuration code and a request signal, a charging mode display part in each of the plurality of terminal 
devices for displaying the at least one charging mode for at least one of the offered and the selected 
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software and the offered and the selected data, and a charging mode confirmation part in each of the 
plurality of terminal devices for specifying the charging mode (see column 68, lines 17-29). 

As per claim 14, Kobata in view of Nakagawa further disclose that the software and data that can 
be downloaded onto a plurality of terminal devices include update software and update data for updating 
software and data stocks that are stored in the plurality of terminal devices (see Nakagawa column 67, 
lines 23-29). 

As per claim 22, Kobata in view of Nakagawa further disclose an offer display part for displaying 
offer information that is transmitted by the central server and a requesting part for selecting at least one of 
software and data that is offered for downloading for the purpose of outputting at least one of a request 
signal and reject signal to the central server (see Kobata column 5, lines 41-44, where accepting certain 
version implies an accept signal for the version wanted and a reject signal for the version unwanted). 

As per claim 24, Kobata in view of Nakagawa further disclose operating data transmitting and 
receiving parts for transferring at least one of software and data to and from the central server (see 
Kobata columns 4 and 5, lines 57-67 and 1-18). 

4. Claims 5,6 are rejected under 35 U.S.C. 1 03(a) as being unpatentable over Kobata in view of 
Nakagawa as applied to claim 1 above, and further in view of Chen et al. (U.S. 5,797,016), herein 
referred to as Chen. 

As per claim 5, although Kobata in view of Nakagawa discloses substantial features of the 
claimed invention (discussed above), he fails to directly disclose a system where software can be stored 
and transferred to and from the server and terminal device. However, these features are well known in 
the art and would have been an obvious modification of the system disclosed by Kobata in view of 
Nakagawa, as evidenced by Chen. 

In an analogous art, Chen discloses a system with a backup server for storing files for current 
software configurations (column 3, lines 32-34) from a terminal device (column 4, lines 39-43, where files 
can also be transmitted from the server to the terminal device [column 2, lines 63-67]), as claimed above. 
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Given the teaching of Chen, a person having ordinary skill in the art would have readily recognized the 
desirability and advantages of modifying Kobata in view of Nakagawa by employing a server that can 
store files from terminal devices, such as disclosed by Chen, in order to backup current software 
configurations incase new installations are not successful, the old software can be restored (column 3, 
lines 32-34). 

As per claim 6, Kobata in view of Nakagawa in view of Chen further disclose that the operating 
data receiving and transmitting parts of both the central server and the plurality of terminal devices are so 
connected to the distributed control parts for implementing the interactive control that the data storage in 
the central server occurs only upon the selection of a corresponding offer by a user of the terminal device 
(column 4, lines 37-43, creation of the back job is considered conditional on the part of the administrator). 

5. Claims 7,12,13,23 are rejected under 35 U.S.C. 103(a) as being unpatentable over Kobata in 
view of Nakagawa as applied to claims 1 and 21 above, and further in view of Valentine (U.S. 6,01 8,654). 

As per claims 7 and 23 although Kobata in view of Nakagawa discloses substantial features of 
the claimed invention (discussed above), he fails to directly disclose network-specific signaling parts on 
the basis of a SIM card. However, these features are well known in the art and would have been an 
obvious modification of the system disclosed by Kobata in view of Nakagawa, as evidenced by Valentine. 

In an analogous art, Valentine disclose a system with a server with a transmitting part for 
transmitting software to mobile devices [Figure 3, (170, 20)] using signaling parts on the basis of a SIM 
card (column 3, lines 7-12). 

Given the teaching of Valentine, a person having ordinary skill in the art would have readily 
recognized the desirability and advantages of modifying Kobata in view of Nakagawa by employing 
signaling parts on the basis of a SIM card, such as disclosed by Valentine, in order to interactively 
download software (see Fig. 4, and columns 4, lines 15-27). 

As per claim 12, although Kobata in view of Nakagawa discloses substantial features of the 
claimed invention (discussed above), he fails to directly disclose software for implementing non-network- 
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bound auxiliary functions. However, these features are well known in the art and would have been an 
obvious modification of the system disclosed by Kobata in view of Nakagawa, as evidenced by Valentine 

Valentine discloses a system with a server with a transmitting part for transmitting software to 
mobile devices [Figure 3, (170, 20)] where the software being transmitted is non-network bound (column 
1 , lines 44-52, where tone data is considered non-network bound). Given the teaching of Valentine, a 
person having ordinary skill in the art would have readily recognized the desirability and advantages of 
modifying Kobata in view of Nakagawa by employing software for implementing non-network-bound 
functions such as ring tones, such as disclosed by Valentine, in order to provide users with entertainment 
or, in the case of ring tones, help them determine the caller without picking up the phone (column 1 , lines 
29-38). 

As per claim 13, it would have been obvious to a person having ordinary skill in the art to offer 
software for implementing auxiliary services, since the type of software is simply a choice left up to the 
designer. The desirability and advantages of implementing auxiliary services would be for conveniently 
allowing the user to connect to the Internet using well-known applications such as a web browser or IM 
chat client. 

6. Claim 8 is rejected under 35 U.S.C. 103(a) as being unpatentable over Kobata in view of 
Nakagawa as applied to claims 1 and 15 above, and further in view of Pepe et al. (U.S. 5,742,668). 

Although Kobata in view of Nakagawa disclose substantial features of the claimed invention 
(discussed above), he fails to directly disclose a central server, which acts as an intermediate station 
between two terminal devices for loading data from one terminal device to another. However, these 
features are well known in the art and would have been an obvious modification of the system disclosed 
by Kobata in view of Nakagawa, as evidenced by Pepe et al. 

In an analogous art, Pepe et al. disclose a telecommunications network with a central server used 
for transmitting data between devices (column 13, lines 29-39). Devices include cellular phones, PDAs, 
and email from workstations [Figure 1, (32, 30, 22)]. 
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Given the teaching of Pepe et al., a person having ordinary skill in the art would have readily recognized 
the desirability and advantages of modifying Kobata in view of Nakagawa by employing a central server 
to act as an intermediate station to load software between devices, such as disclosed by Pepe et al., in 
order to communicate messages between devices from anywhere at anytime (column 1 , lines 42-43). 

7. Claims 9-1 1 ,25 rejected under 35 U.S.C. 1 03(a) as being unpatentable over Kobata in view of 
Nakagawa as applied to claims 1,21 above, and further in view of Shear (U.S. 4,977,594). 

As per claim 9, although Kobata in view of Nakagawa discloses substantial features of the 
claimed invention (discussed above), he fails to directly disclose determining the validity of software and 
usage authorization. However, these features are well known in the art and would have been an obvious 
modification of the system disclosed by Kobata in view of Nakagawa, as evidenced by Shear. 

In an analogous art, Shear discloses a system for distributing data with a validation storage unit 
for storing authorization data, and determining the validity of data of terminal devices (column 14; lines 
29-36). 

Given the teaching of Shear, a person having ordinary skill in the art would have readily 
recognized the desirability and advantages of modifying Kobata in view of Nakagawa by employing the 
validation storage unit, such as disclosed by Shear, in order to bill the user according to the amount of 
resources used (column 3, lines 52-59). In a software/data distributing environment where resources are 
not free, it would be advantageous for the supplier of the software/data to keep track of the software 
being deployed in order to charge the appropriate amount to the user. 

As per claim 1 0, Kobata in view of Nakagawa in view of Shear further disclose that the software 
stocks and data stocks that are one of implemented in the plurality of terminal devices and downloaded 
into the plurality of terminal devices include application counter elements, the central server further 
including an arithmetic evaluation unit for evaluating the counter statuses of the application counter 
elements at one of predetermined times, time intervals, and times when the relevant terminal device logs 
onto the telecommunication network, for the purpose of achieving a use-based charging mode (see Shear 
column 13, lines 47-60). 
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As per claims 1 1 ,25, Kobata in view of Nakagawa in view of Shear further disclose that the server 
includes an auxiliary information transmission unit which is connected to at least one of the comparison 
unit and the arithmetic evaluation unit for transmitting messages to the respective terminal device relating 
to at least one of the validity of implemented software, the usage authorization, and the application 
counter status for the respective user, the plurality of terminal devise including auxiliary information 
reception and display units for receiving and displaying the messages (see Shear column 15, lines 33- 
47). 



8. Claims 15,17 are rejected under 35 U.S.C. 103(a) as being unpatentable over Kobata, and further 
in view of Shah (US 6,029,065) and further in view of Nakagawa (US 5,838,91 1). 

As per claim 15, Kobata discloses a method of operating a telecommunication network having a 
plurality of terminal devices of users, each with a predetermined hardware and software configuration, 
and a central server of an access or service provider, the method comprising the steps of: 

interrogating the current hardware and software configurations of one of the plurality of terminal 
devices in an interrogation step at one of a time during logon onto the telecommunication network, 
predetermined times, and time intervals; 

transmitting, in a transmission step, the current hardware and software configuration of the 
respective terminal device to the central server; 

setting up in the central server and transmitting to the respective terminal device, based on the 
respectively transmitted hardware and software configuration, offer information for a user of a respective 
terminal device; and 

downloading onto the respective terminal device by the central server, in response to the 
registered one of the request and the reject signals, software and/or data that are suitable for the 
respective terminal device and that are not already present at the terminal device (see column 5, lines 1- 
18). 

Although the system disclosed by Kobata shows substantial features of the claimed invention 
(discussed above), it fails to disclose displaying, in the context of an interactive menu in the respective 
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terminal device, the offer information together with one of a select and a reject request, one of a request 
and a reject signal of the user which is generated by the user being registered. 

Nonetheless, these features are well known in the art and would have been an obvious 
modification of the system disclosed by Kobata, as evidenced by Shah. 

In an analogous art, Shah discloses a system where a mobile station can select a desired feature 
available to the mobile station (see Abstract) further, further showing an interactive menu in the 
respective terminal device with one of a select and reject request, one of a request and a reject signal of 
the user which is generated by the user being registered (see column 9, lines 54-61). 

Given the teaching of Shah, a person having ordinary skill in the art would have readily 
recognized the desirability and advantages of modifying Kobata by employing an interactive menu, such 
as disclosed by Shah, in order to allow a user to easily pick which features they want to implement. 

Although the system disclosed by Kobata in view of Shah shows substantial features of the 
claimed invention (discussed above), it fails to disclose displaying the charging mode signals in the 
context of the interactive menu for selection by the user, and registering a charging mode in the central 
server in response to a selection made by the user. 

Nonetheless, these features are well known in the art and would have been an obvious 
modification of the system disclosed by Kobata in view of Shah, as evidenced by Nakagawa et al. 

In an analogous art, Nakagawa discloses a software distributing system for updating a client with 
current software (see Abstract) and further specifying a charging mode for at least one of downloaded 
software and downloaded data (see column 68, lines 17-29). 

Given the teaching of Nakagawa, a person having ordinary skill in the art would have readily 
recognized the desirability and advantages of modifying Kobata in view of Shah by employing interactive 
control and a charging mode, such as disclosed by Nakagawa, in order to allow the user to choose 
different methods of payment that may suit their needs. 

As per claim 17, although Kobata in view of Shah in view of Nakagawa discloses substantial 
features of the claimed invention (discussed above), it fails to directly disclose a filtering method based on 
previously rejected software by the terminal device. However, it would have been obvious to a person 
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having ordinary skill in the art to stop offering software, which the terminal device has rejected. The 
desirability and advantages of having such a filtering means would be for the convenience of the user 
since the user would not have to continually decline the same software they do not want, analogous to a 
software system for allowing a user to stop checking for software updates by checking a box. 

9. Claims 19,20 rejected under 35 U.S.C. 103(a) as being unpatentable over Kobata in view of Shah 
in view of Nakagawa as applied to claims 1 ,21 above, and further in view of Shear (U.S. 4,977,594). 

As per claim 19, although Kobata in view of Shah in view of Nakagawa discloses substantial 
features of the claimed invention (discussed above), he fails to directly disclose determining the validity of 
software and usage authorization. However, these features are well known in the art and would have 
been an obvious modification of the system disclosed by Kobata in view of Shah in view of Nakagawa, as 
evidenced by Shear. 

In an analogous art, Shear discloses a system for distributing data with a validation storage unit 
for storing authorization data, and determining the validity of data of terminal devices (column 14, lines 
29-36). 

Given the teaching of Shear, a person having ordinary skill in the art would have readily 
recognized the desirability and advantages of modifying Kobata in view of Shah in view of Nakagawa by 
employing the validation storage unit, such as disclosed by Shear, in order to bill the user according to 
the amount of resources used (column 3, lines 52-59). In a software/data distributing environment where 
resources are not free, it would be advantageous for the supplier of the software/data to keep track of the 
software being deployed in order to charge the appropriate amount to the user. 

As per claim 20, Kobata in view of Shah in view of Nakagawa in view of Shear further disclose 
evaluating in the central server, when at least one of a terminal device logs on, predetermined times 
occur, and time intervals occur, counter statuses of application counter elements of the software and data 
stocks that are implemented in the plurality of terminal devices for the purpose of performing a use-based 
charging, an evaluation result being transmitted to the plurality of terminal devices (see Shear column 1 3, 
lines 47-60). 
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10. Claim 16 is rejected under 35 U.S.C. 103(a) as being unpatentable over Kobata in view of Shah 
in view of Nakagawa as applied to claim 15 above, and further in view of Chen et al. (U.S. 5,797,016), 
herein referred to as Chen. 

Although Kobata in view of Shah in view of Nakagawa discloses substantial features of the 
claimed invention (discussed above), he fails to directly disclose a system where software can be stored 
and transferred to and from the server and terminal device. However, these features are well known in 
the art and would have been an obvious modification of the system disclosed by Kobata in view of Shah 
in view of Nakagawa, as evidenced by Chen. 

In an analogous art, Chen discloses a system with a backup server for storing files for current 
software configurations (column 3, lines 32-34) from a terminal device (column 4, lines 39-43, where files 
can also be transmitted from the server to the terminal device [column 2, lines 63-67]), as claimed above. 
Given the teaching of Chen, a person having ordinary skill in the art would have readily recognized the 
desirability and advantages of modifying Kobata in view of Shah in view of Nakagawa by employing a 
server that can store files from terminal devices, such as disclosed by Chen, in order to backup current 
software configurations incase new installations are not successful, the old software can be restored 
(column 3, lines 32-34). 

Claim 18 rejected under 35 U.S.C. 103(a) as being unpatentable over Kobata in view of Shah in 
view of Nakagawa as applied to claims 1 and 15 above, and further in view of Pepe et al. (U.S. 
5,742,668). Although Kobata in view of Shah in view of Nakagawa disclose substantial features of the 
claimed invention (discussed above), he fails to directly disclose a central server, which acts as an 
intermediate station between two terminal devices for loading data from one terminal device to another. 
However, these features are well known in the art and would have been an obvious modification of the 
system disclosed by Kobata in view of Shah in view of Nakagawa, as evidenced by Pepe et al. 
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In an analogous art, Pepe et al. disclose a telecommunications network with a central server used 
for transmitting data between devices (column 13, lines 29-39). Devices include cellular phones, PDAs, 
and email from workstations [Figure 1, (32, 30, 22)]. 

Given the teaching of Pepe et al., a person having ordinary skill in the art would have readily recognized 
the desirability and advantages of modifying Kobata in view of Shah in view of Nakagawa by employing a 
central server to act as an intermediate station to load software between devices, such as disclosed by 
Pepe et al., in order to communicate messages between devices from anywhere at anytime (column 1 , 
lines 42-43). 

Response to Arguments 

1 1 . Applicant's arguments filed November 25, 2005 have been fully considered but they are not 
persuasive. 

(A) Applicant contends that in the claimed invention the interrogation of the hardware and software 
configurations of the terminal devices is initiated by the server. 

(B) Applicant contends Nakagawa contains no distributed control means that are arranged in both the 
server and the client. 

(C) Applicant contends there is no teaching, suggestion or motivation for one of ordinary skill in the 
art to combine Kobata/Nakagawa and Kobata/Shah references. 

In considering (A), the Examiner believes that the claim is unclear as to whether the server 
initiates the communication. It is understood that the client responds to an inquiry by the interrogation 
part, but the claim does not specifically state if the server or client is the first to engage. The Examiner 
invites the Applicant to clearly indicate that the server is the first to initiate communication. Kobata is still 
pertinent even if initial communication is originated from the server because as shown in column 4, lines 
57-column 5, line 18, a server sends out a package to client to check the infrastructure data of the client 
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(i.e. CPU info HD space, etc.), then pushes content onto the client which is suitable based on the 
infrastructure. 

In considering (B), the Examiner respectfully disagrees. The system of Nakagawa requires 
interaction of both the server and the client. Without both, a client would not be able to request for 
purchase information at all. Examiner invites the applicant to elaborate on how the client executes the 
interactive specifying. 

In considering (C), the Examiner respectfully disagrees. In response to applicant's argument that 
there is no suggestion to combine the references, the examiner recognizes that obviousness can only be 
established by combining or modifying the teachings of the prior art to produce the claimed invention 
where there is some teaching, suggestion, or motivation to do so found either in the references 
themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 
F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988)and In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 
1 992). In this case, both systems require the knowledge of a clients software/hardware configuration in 
order to deliver content accordingly. A person of ordinary skill in the art would recognize the similarity 
between the systems regarding the functional pieces of hardware. 

Conclusion 

1 2. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth 
in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE MONTHS from 
the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date 
of this final action and the advisory action is not mailed until after the end of the THREE-MONTH 
shortened statutory period, then the shortened statutory period will expire on the date the advisory action 
is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later than SIX 
MONTHS from the mailing date of this final action. 
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Any inquiry concerning this communication or earlier communications from the examiner should 
be directed to Philip J. Chea whose telephone number is 571-272-3951 . The examiner can normally be 
reached on M-F 7:00-4:30 (1st Friday Off). 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, 
Glenn Burgess can be reached on 571-272-3949. The fax phone number for the organization where this 
application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent Application 
Information Retrieval (PAIR) system. Status information for published applications may be obtained from 
either Private PAIR or Public PAIR. Status information for unpublished applications is available through 
Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) 
at 866-217-9197 (toll-free). 
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Examiner 
Art Unit 2153 
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[57] ABSTRACT 
A pet food product containing at least one amylaceous 
ingredient maintains or improves its soft texture during 
storage when the enzyme a-amylase is added thereto 
and processed using heat. 
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upon storage while avoiding adverse effects on its palat- 
i-AMYLASE ability. 

These and other objects of this invention are accom- 
plished by adding an effective amount of a-amylase 
This application is a continuation of application Ser. 5 containing material to a food product, processing the 
No. 262,252, filed May 11, 1981, now abandoned. food product using heat without completely inactivat- 

BACKGROUND OF THE INVENTION ™ g the "TXl" 8 * J" 1 * 1 ? m h ° lding SUCh • pr ° dUCt in 

storage such that the soft texture is maintained or im- 
This invention relates to food products and more proved upon storage, 
particularly to food products of an amylaceous charac- 10 „ _ 

ter containing heat stable a-amylase which is added in DESCRIPTION OF THE PREFERRED 

amounts sufficient to maintain or improve the soft tex- EMBODIMENTS 
ture after a heat treatment. A food product containing an amylaceous ingredient, 

While it is well recognized that many features con- such as cereal grains, maintained or improved its texture 
tribute to the taste of a food, it is equally well recog- 15 due to the addition of an effective amount of active 
nized that an important taste feature of a food is its a-amylase. 

texture, or, the relative softness of the food. A food that The amount of a-amylase suitable for use in this in- 
feels hard or conversely, extremely soft or mushy may vention varies substantially depending on the type of 
not be acceptable, the desired texture lying generally food product in which it is to be used, and can be easily 
somewhere in the intermediate range. Foods such as 20 determined by a person having ordinary skill in the art. 
meat or meat substitutes are usually expected to be Generally speaking, from a trace to about 5000 SKB 
relatively soft. Some products though initially of a soft units of a-amylase is added for each kilogram of starch 
texture, such as bread, are known to stale and become in the food being made and is present in the food after 
hard upon storage. No imagination is needed to realize processing. More preferably, from about 0.25 SKB units 
that with a wide variety of foods, texture or, retaining a 25 to about 2000 SKB units per kilogram of starch in the 
soft texture, can be a large problem. product is in the food after processing. Even more pref- 

Even though it is possible to manufacture a food erably, about 0.5 SKB units per kilogram of product to 
product having initially the desired soft texture, staling about 1000 SKB units per kilogram of starch in the 
and the like are factors encountered on storage which product may be added to achieve the appropriate levels 
can have an adverse effect on texture. 30 in the food product after processing. The reference to 

Because such hardness and change in texture is inher- SKB units is well known in the art as a definition for 
ently undesirable in most food products, it thus becomes amylase activity as set forth in Sanstedt, et, al., Cereal 
clearly desirable to prevent this change in texture or Chemistry, Vol. 16, page 712, (1939). A factor to be 
reduce the texture deterioration in a stored food. considered in determining the effective amount of en- 

Procedures are known in the prior art for achieving a 35 zyme to be used to achieve a desired texture in a food 
food having a soft texture by addition of such ingredi- product is the moisture content of the food product, 
ents as humectants. In some cases, a food which is man- Unless the food product contains over fifteen percent 
ufactiired with a soft texture has such a low amount of moisture, only minimal or no texturizing effect will be 
texture deterioration that storage is highly feasible for noted. Based on current observations, it would appear 
that food without a substantial loss in texture. Even in 40 that appreciable enzymatic activity of the a-amylase 
these cases, there is some loss of texture which can occurs only at moisture levels above about fifteen per- 
become detrimental if the storage is overly extended. cent. 

The components generally used to achieve the desired a- Amylase is a well known enzyme, having an IUB 
texture are costly and can have a somewhat adverse number of 3.2.1.1, which defines a-amylase in an inter- 
effect on palatability. 45 nationally accepted manner. It is also known as 1,4-a-D 

Besides the use of humectants as taught in U.S. Pat. glucan glucanohydrolase. a-Amylase is generally pres- 
No. 3,202,514 to Burgess, another way to achieve and ent in all amylaceous materials at low levels and, by 
maintain a soft texture is through the use of certain previous practices, was generally reduced to a low 
emulsifiers which tend to complex with the starch, ineffective concentration or activity level by baking, 
thereby retarding starch degradation. However emulsi- 50 According to the subject invention, d-amylase is now 
fiers only slow down the rate of staling, and do not added to the food product in quantities, that will assure 
completely inhibit it. a sufficiently high activity level after processing to 

It has been known in the past to add an amylase en- maintain or improve the texture of the food product. In 
zyme to bakery products such as breads, to achieve a this manner texture deterioration in the food product is 
softening of the bread texture. However, in the baking 55 avoided even after storage. 

process, the bread dough is cooked at a sufficiently high While not completely understood, it is theorized that 
temperature for a sufficiently long time to assure inacti- within an amylaceous product the active a-amylase 
vation of the enzyme during baking. Thus no texturiza- present reacts to hydrolyze the starch, thus reducing the 
tion of the bread can occur after baking, and the bread amount of long starch chains available for retrograda- 
also will become hard or stale with time. 60 tion, and resulting in a soft texture throughout the entire 

SUMMARY OF THE INVENTION product. However the starch does not become suscepti- 

auMMAK i vr iHfclNVUNllUN ble to the action of the enzyme until gelatinization of the 

Therefore, an object of the subject invention is a food starch occurs at temperatures destructive to the a-amy- 
product and a process for preparing a soft food product lase. As a result, the heat processing of a food product 
having a texture which can be maintained during stor- 65 generally inactivates the enzyme, allowing a staling 
age. process to go forward unless other measures are taken. 

A still further object of the subject invention is a food For instance, the amylase content of a bread dough may 
product, such as a pet food, having improved texture affect the texture of the bread initially, however the 
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softness of the bread begins to deteriorate as soon as the drolyze the starch thus reducing the long starch chain 

baking is completed. available for retrogradation. The resultant product is 

The rate and degree of softening of the food is depen- less apt to stale because most of the starch components 

dent upon the activity of the enzyme used, the presence not already in the crystalline state are hydrolyzed and 

and amount of free moisture, enzyme, chloride ion, 5 cannot retrograde. The hydrolysis of the starch does 

calcium, the pH and temperature of the product. The not take place appreciably until the starch is gelatinized, 

a-amylase may be derived from bacterial, fungal, ani- of course, if pregelatinized starch sources are used 

mal, cereal or vegetable sources. Bacterial amylase is rat her than unprocessed starch sources, enzymatic hy- 

preferred for the purpose of this invention because it is drolysis of the starch will take place in the product 

readily available, can be readily adapted for use in 10 doug h. Thus, by adding the a-amylase and maintaining 

foods, and is more heat stable. o-Amylase generally is , ts activity through a judicious choice of processing 

active m a pH range of about 2 to 11 with a moisture parameters with regard to temperature and time as set 

content of over 10-15%. The preferred pH range for forth abovef the a . amy i ase can hydrolyze the gelati- 

a-amylase activity is in the 4 to 8 range. Most foods nized starch in a cont rolled manner, even during stor- 

contam sufficient amount of chloride, in the form of salt 15 age . In this fashion> the duct cannot on] retain its 

and calcium to activate the enzyme. If calcium is not initial soft texture> but can even become softer wi(h the 

present in the food, any suitable source from edible salts passa g e of time 

may be added, such as calcium phosphate and calcium Another advantage in adding a . araylase is ^ im _ 

su Z.„ e " „. r , . . , „ „„ provement in palatability upon storage. It is theorized 

Effective processing of an amylaceous food produc 20 ^ thfi matic hydrolysis mcTeaS es the sweetness of 

generally depends on temperature and time and must the duct dufi J > si d rf f . 

be sufficient to cook the food and gelatinize the starch, tQ . J * ' J 

words, for an extruded product the temperature and . . . — , , j • J 
residence time in an extruder must be sufficient to cook 25 a " d S f weet P roduct ^ a " am y lase P roduces ^ such 
the food and gelatinize the starch, yet insufficient to e " e - c . ° n stora S e ; . . 
inactivate the a-amylase. Processing temperatures of If ' ,ndeed ; a P et food 15 des ' red to be form f ^ 
food containing a-amylase can range up to 150' C. for ^mylase, « must contain a sufficient amount of protein 
short periods of time with the effective amounts of the { ™ m elther an an,mal sou u rce ' a r cereal source a vegeta- 
added a-amylase remaining active. However, it is more 30 ble souree < or ™xtures thereof to provide the protein 
preferable to operate at process temperatures between requirements as set forth by the National Research 
75« C. and 110° C, which is an effective temperature Co,mc,L Also - other ingredients to provide a suitable 
range for achieving most food processing and stabiliza- P et food mav be '"eluded, as known in the art. 
tion. It is critical that the a-amylase not be totally or As indicated, the protein source for a pet food prod- 
substantially inactivated by such conditions as overly 35 uot 1S e,ther a vegetable protein source, a cereal protein 
high temperatures or long retention times during pro- source, an animal derived protein source, or a combina- 
cessing. 'ion thereof. The critical point of the protein source is 

Generally speaking, the higher the temperature of the that k must provide the nutritional and legal require- 

extruder, the lower the residence time the food is per- ments for th e protein in the product. Generally speak- 

mitted to be in the extruder. Preferably, from entry into 40 ln S> the protein content in the pet food must be at least 

the extruder to exit from the extruder, the time frame about 5 percent to about 50, and more preferably 10 

may be from 5 seconds to 15 minutes, dependent chiefly percent to 40 percent on a dry basis. Protein levels are 

on the extruder used and the output rate. critical depending on the type of pet food being fed. A 

Comparison tests of food with and without a-amylase d °g food protein content is advantageously above 22 
added show that extruded foods with a-amylase added 45 percent by weight of the pet food on a dry basis while 
are at least 5 percent softer and sometimes 10 to 50 a cat food protein content is advantageously above 28 
percent softer than the extruded foods without a-amy- percent by weight on a dry basis which are recommen- 
lase added, when stored for the same period of time dations made by National Research Council for dogs 
under the same conditions. Thus food products without and cats respectively to have a completely nutritional 
the a-amylase added, that is, containing only natural 50 food- 
levels of the enzyme, experienced a staling or hardening The starch content of the food product of the subject 
effect, while the food products with the additional a- invention may vary from 10% to 60% of the total ingre- 
amylase were at least as soft as the original texture, and dients. A starch content less than 10% may not provide 
sometimes softer as measured by the standard methods a significant enough texturizing effect on the food prod- 
used for determining the softness of the food, i.e., the 55 uct to be noticeable, while more than 60% starch can 
Kramer Shear Press method or alternatively by the result in an excessively soft texture. Such starches will 
Instron method, both known in the art. usually originate predominately from cereal grains; 

While this concept is applicable to any type of food, however other sources, such as tubers and legumes, 

it is especially applicable to semi-moist foods because a may be used. 

soft and moist texture is of considerable importance in 60 The subject invention has been found particularly 
semi-moist human or pet foods. While in the past the useful in maintaining and enhancing the texture of semi- 
desired texture has been accomplished by adding con- moist pet foods. A typical semi-moist pet food of about 
siderable amounts of plasticizers or humectants, these 15 percent to about 40 percent moisture content has 
ingredients are now not necessary to provide a soft about 3 percent to about 65 percent of a protein source, 
texture. The presence of the added a-amylase with the 65 which may comprise meat, vegetable, meat meals or 
other ingredients during processing provides the de- mixtures thereof. A preservative system comprising 
. sired soft texture without added humectants or plasti- sugars, edible acids and antimycotic agents may be 
cizers. As stated above, the enzyme is believed to hy- utilized as described in U.S. Pat. No. 3,202,514. Other 
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additives, such as vitamins, minerals, colorants, flavor- 
ants, and salts may be added as desired. 

While the invention is now clearly disclosed as to 
how to make and use the invention, the following Ex- 
amples are presented to guarantee an understanding of 5 
the invention without necessarily limiting the invention. 
All parts and percentages are by weight unless other- 
wise specified. 



following measurements we 
ucts using a shear cell on a 
Machine, Model II: 



e made on the stored prod- 
Instron Universal Testing 



EXAMPLE I 



10 _ 



Sample Size: 40 gm 
Stroke Length: 6 gm 
Stroke Speed: 10 cm./min. 
Full Scale: 50 Kg. full scale 



EXPANDED SEMI-MOIST PET FOOD 



Product Measurements 



Meat and Bone Meal 
Wheat Flour 
Oatmeal 
Soy Flour 
Propylene Glycol 
Ground Yellow Corn 
Animal Fat 
Oat Flour 
Phosphoric Acid 
Potassium Sorbate 



As can be seen, the Instron measurements confirmed 
the improved softness observed in the stored sample 
> containing a-amylase enzyme. 



EXAMPLE III 



NON-EXPANDED SEMI-MOIST PET FOOD 
' E Without F With 

Ingredients q-Amylase o--Amylase 



The above products were processed on a Bonnot 30 
extruder at 225° F. The resulting products each had 
bulk densities of 31 lbs/ft. 3 and moisture contents of 
30%. Both samples were identical in appearance and 
texture when first made. However, after 8 months of 
storage at both 73" F. and 100° F., the product contain- 35 
ing the a-amylase enzyme was considerably softer. 
Both stored products were measured for softness on the 
Kramer Shear Press with the following results: 



Meat By-Products 

Wheat Flour 

Soybean Flour 

Com Syrup 

Propylene Glycol 

Corn Flour 

Phosphoric Acid 

Potassium Sorbate 

Vitamins, Minerals, Color, e 

a-Amylase' 



19.0 pts 
6.0 pts 
5.0 pts 
4.0 pts 



25.0 pts 
25.0 pts 
19.0 pts 

6.0 pts 

5.0 pts 

5.9 pts 
600 SKB Units/ 
. kg. Starch 

30.0 pts 



-40 



Maximum Peak Maximum Peak 
SAMPLE Height at Height at 

Age 73* F. Storage 100' F. Storage 



The data from the Kramer Shear Press readings con- 
firmed the observed softer texture of the product con- 
taining a-amylase. Also, the higher storage temperature 
seemed to increase the amount of softening by the en- , 
zyme, which was apparent both by observation and by 
the Kramer Shear Press readings. 

EXAMPLE II , 
EXPANDED SEMI-MOIST PET FOOD 55 " 

A formulation similar to that in Example I was used 1 
to test the texture softening action of Miles Taka- 1 
Therm® a-amylase, an amylase having a different 
activity level than Miles HT-1000. As in Example I, the 1 
only difference was that one contained 100 SKB 60 j 
units/kg-starch MUes Taka-Therm (g) a-amylase (D) 
and the other (C) did not. 

Both products were processed at 230° F. in an ex- 
truder, and had finished product moisture contents of 
30%, being expanded to a density of 32 lbs/ft. 3 . No 65 
differences in product texture were observed initially, 
but after 3£ months of ambient storage, the product 
containing the a-amylase was considerably softer. The 



The above products were processed on a Bonnot 
extruder at 190° F. The products were made in a strand 
form at a finished product moisture content of 30%, and 
. were tested for palatability initially and after 9 months 
of ambient storage. After nine months the observed 
softness of the product F (with a-amylase) was greater 
than product E (without a-amylase). A standard 2 bowl 
preference method was used to obtain the following 
i results on palatability: 

% Level of Statistical 



99% (Highly Significant) 



According to the above data there was no initial 
significant difference in the palatability of the products 
with or without a-amylase. However, after nine months 
of storage, not only was the product with enzyme noti- 
cably softer, but it was significantly more palatable than 
the same product without the enzyme. 



4,540,585 



EXAMPLE IV 



The procedure of Example III is applied to the fol- 
lowing formulation: 



Ingredients 

Granola Mix 

(Oat flakes, Wheat flakes, 

Nuts, Honey, etc.) 

Glycerol 
Shortening 

Vitamins, Minerals, Flavor, 
Phosphoric Acid, and 
Potassium Sorbate 



Water 



20. SKB Units/kg. Starch 
28 pts 

100. 



The product of Example 4 results in a granola snack 
bar which maintains a soft product texture over an 
extended shelflife without becoming hard or crumbly in 
texture. The a-amylase maintains the desired texture, 
but does not hydrolyze to the point where the product 2 s 
becomes too soft. 

The above examples show that a-amylase is useful as 
a texturizing agent, not only preventing the degradation 
of a soft texture of a food product but even contributing 
to the improvement of the texture of the food product 30 
on storage. As stated and as demonstrated in the exam- 
ples, the subject invention applies to all food products 
having amylaceous ingredients, regardless of whether 
the food product is for humans or for pets. 

While the invention has been described with refer- 35 
ence to a preferred embodiment, it will be understood 
by those skilled in the art that various changes may be 
made and equivalents may be substituted for elements 
thereof without departing from the scope of the inven- ^ 
tion. In addition, many modifications may be made to 
adapt a particular situation or material to the teachings 
of the invention without departing from the essential 
scope thereof. Therefore, it is intended that the inven- 
tion not be limited to the particular embodiment dis- 45 
closed as the best mode contemplated for carrying out 
this invention, but that the invention will include all 



embodiments falling within the scope of the appended 
claims. 
I claim: 

1. In a soft, semi-moist pet food product consisting of 
soft, cohesive, extrusion cooked particles having 
10-60% starch, 22-50% protein, 5-35% water soluble 
solutes, and 15-40% moisture; the improvement com- 
prising: 

an enzyme in the pet food product consisting essen- 
tially of alpha-amylase, wherein the alpha-amylase 
is in an active condition and wherein the active 
condition alpha-amylase is in the pet food in suffi- 
cient quantity to maintain the soft texture of the pet 
food product during subsequent storage. 

2. The improved pet food product according to claim 
1 wherein the improved pet food product has a pH in 
the range 2-10. 

3. The improved pet food product according to claim 
1 wherein the alpha-amylase is present in the improved 
pet food product in an amount from a trace to 5,000 
SKB units of alpha-amylase for each kilogram of starch. 

4. In a method for makig a soft, semi-moist pet food 
by the steps of admixing a dough having at least one 
amylaceous ingredient, at least one proteinaceous ingre- 
dient selected from animal, vegetable or cereal sources, 
sufficient water to provide a moisture content in the pet 
food product in the range 15-40% and at least one 
water soluble solute selected from sugars and polyols; 
and extrusion cooking the dough at a temperature in the 
range 75"- 110° C. inclusive for a time period in the 
range 15 seconds to 5 minutes inclusive, the improve- 
ment comprising: 

(a) adding to the dough an enzyme ingredient consist- 
ing essentially of a heat-stable alpha-amylase en- 
zyme; 

(b) extrusion cooking the dough containing alpha- 
amylase at a temperature and for a time period 
sufficiently mild that at least some alpha-amylase 
remains active in the extrusion cooked pet food 
product; and 

(c) storing the pet food product containing the active 
alpha-amylase. 

5. The improved process according to claim 4 
wherein from a trace of 5000 SKB units of alpha-amy- 
lase for each kilogram of amylaceous ingredient is 
added to the dough. 
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[57] ABSTRACT 

A number of sets of software may be systematically distrib- 
uted and maintained via a network connecting many vendors 
and users of client/server software. A client program in a 
user computer detects when software subject to maintenance 
is activated and transmits an inquiry over the network to the 
software vendor's computer for information on the current 
version of the software. The server program compares data 
in the inquiry with data relating to the latest version of the 
software and returns update instruction information and 
updated software if appropriate. The client program auto- 
matically updates the software to the latest version accord- 
ing to the update instruction information when it is received. 
The client program can also send inquires at predetermined 
times, or in response to a user command. The inquiry can 
include a request for purchase information in which case the 
server checks qualifications of the user, processes the 
inquiry according to vendor management data and returns 
the requested software, if appropriate. Other inquiries can 
also be made in response to user commands or 
automatically, e.g., to obtain information on the most recent 
version and transmission of data from client to server in 
response to an abnormal termination of client software. 
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FIG. 12 



ACTIVATING 



[CLIENT 
PROGRAM (CP)] ^- S31 

STANDBY STATE I 



S32 



ACTIVATING BY USER OR OBJECT 
SOFTWARE, OR RECEIVING MESSAGE 
THROUGH NETWORK 



[USER PROCEDURE 
(UP)] 



S33 



ANALYZING COMMAND (USER NAME, 
COMMAND NAME, AND SOFTWARE NAME) 
PERFORMING SUBSEQUENT PROCESSES 
FOR THE SPECIFIED USER 




EDITING MESSAGE 
FOR THE SPECIFIED 

COMMAND IN 
INTERACTIVE MODE 



SENDING , 



S36 



AUTOMATICALLY 
EDITING MESSAGE 
FOR THE SPECIFIED 
COMMAND 

1 



_ (INQUIRY/REQUEST JL 
^EDITING PROCEDURE)^ 1 

SUMMARY INQUIRY NEW 
INSTALLATION REQUEST 
NEW SERVICE REQUEST 
UPDATE INQUIRY FAULT 
INFORMATION ETC. 



(RETRIEVING AND 
CONFIGURING 
INFORMATION 



S37 



SENDING INQUIRY/REQUEST MESSAGE 



-S38 



RECORDING THE MESSAGE AND 
RETURNING TO STANDBY STATE 



U.S. Patent Nov. 10, 1998 Sheet 13 of 24 5,835,911 



SENDING 



FIG. 13 



RECEIVING 
THROUGH 
NETWORK 


r S39 


CONFIRMING STANDBY FOR 
ANSWER AND CONFIRMING 
SENDER 




r S40 


INVOKING ANSWER 
RECEIVING PROCEDURE 
FOR RECEIVED COMMAND 




r S41 



(IF REQUIRED) 
GENERATING AND SENDING 
ANSWER PROCESS RESULT 
ACKNOWLEDGMENT 
MESSAGE 



S42 



RECORDING ANSWER 
RECEIVING PROCESS AND 
RETURNING TO STANDBY 
STATE IN S31 



P2 



; (VENDOR CONFIRMATION. 
PROCEDURE) 

VENDOR CONFIRMATION 
PROCESS 



P3 



(ANSWER RECEIVING_ 
PROCEDURE) ^ 

INSTALLING INITIALLY 
PURCHASED SOFTWARE 

INSTALLING UPDATA 
DATA DISPLAYING AND 

STORING WARNING/ 
NOTICE MESSAGE 



U.S. Patent Nov. 10, 1998 Sheet 14 of 24 



5,835,911 




U.S. Patent 



Nov. 10, 1998 



Sheet 15 of 24 



5,835,911 



0- 



to 



0- 




CO 



CO 



Q 
O 



< 
CD 



U.S. 



Patent Nov. 10, 1998 Sheet 16 of 24 



5,835,911 



FIG. 16 
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SOFTWARE DISTRIBUTION AND 
MAINTENANCE SYSTEM AND METHOD 

CROSS REFERENCE TO RELATED 
APPLICATION 

This application is a continuation-in-part application of 
U.S. patent application Ser. No. 08/385,460 filed an Feb. 8, 
1995, now abandoned. 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to a software distribution 
and maintenance system and method with which a software 
vendor can provide a number of users with software over a 
network, and update and maintain the software at requests of 
the users, and with which the users obtain a lot of software 
from plural software vendors over the network and can use 
the latest versions of the software over the network. 

2. Description of the Related Art 

The well-known prior art to distribute and obtain software 
update information is as follows. 

(a) Method of Distributing Software using Portable Media 
To sell and distribute computer software to users, the 

software is normally stored in portable media such as 
magnetic tapes, floppy disks, etc. 

In this case, it is necessary to provide additional services 
such as correcting bugs, adding functions, and supplying 

If the additional services are to be installed in the users' 
computer systems, the vendors have to visit the users' 
offices, or the users must install necessary services by 
themselves. 

(b) Method of Distributing Software over a Network from a 
Vendor 

Recently, software is transmitted over a communications 
network to users. Information required to correct bugs, add 
functions, and supply new versions can also be provided for 
users from vendors over a network. If a vendor is informed 
of a user address, then the vendor can decide to transmit 
necessary information to the user. 

When computer software is actually updated in user 
computer, the software should be re-installed by the user 
according to the software update information and instruc- 
tions from the vendor of the software. 

(c) Method of Users' Obtaining Software over a Network 
Recently, a user can obtain a software over a network, 

when required, by accessing a software library which is 
stored in a vendor (or an agent) computer file (download). 
Likewise obtained at a request of a user is the information 
about correcting bugs, adding functions, and supplying new 
versions. The vendor only has to manage the library. The 
obtained software is installed, updated, and managed in the 
user computer at the user's responsibility. 

In this case, the software used to obtain a necessary 
software over a network is quite separate from the necessary 
software, and therefore is not used to update the necessary 
software. The user has to decide which software/information 
is to be obtained and is responsible for the access operations. 

(d) Linking and Processing Distributed Software over a 
Network 

Software should be appropriately converted in an execut- 
able format normally by compiling and linking source 
programs. Usually, the source programs are stored in a user 
computer and then compiled and linked when necessary. 
However, the source programs can be stored in another 
computer (that is, the vendor computer). In this case, the 
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user accesses the vendor computer from the user computer 
over a network, then either (1) compiles and links the source 
programs in the vendor computer to download the resultant 
programs or (2) downloads the source programs and then 
5 compiles and links them in the user computer, thereby 
converting the software into an executable format. 

This method fundamentally belongs to the above 
described method (c), but is an easier method of executing 
software. 

10 In this method, the user recognizes that the source pro- 
grams are stored in another computer, and then clearly 
specifies necessary modules and files (for example, specifies 
the name of a file with its version number) to transfer and 
link the programs. The entire process is performed at the 

15 user's responsibility. 

Described below are the prior arts partially similar to the 
above described technology but different in purpose, object, 
and method. 

(e) Automatic Download 

20 This method is used for an electronic notice board. In this 
method, a large amount of news information is stored in a 
central computer, etc., and a terminal computer can access 
the central computer through the network periodically at 
intervals and automatically read new information in a speci- 

25 fied category if newly stored (download). 

In this case, the central computer is regarded as a vendor 
computer, and the terminal computer is regarded as a user 
computer. Object information is news, software (so-called 
freeware), etc. 

30 The software which is automatically downloaded is stored 
as ordinary data, and does not directly update or manage the 
software currently used in the user computer. That is, the 
above described automatic download system does not man- 
age the software currently used by a user. 

35 (f) Mirroring 

A mirroring process is used to access new/updated data 
and obtain the latest information among a plurality of central 
computers, etc. which store and provide a large amount of 
document data, etc. 

40 A central computer is a primary storage center of infor- 
mation of a specific category. Stored information is copied 
to other plural central computers (secondary storage centers) 
for disclosing the stored information. 
To attain this, the secondary storage centers periodically 

45 access the primary storage center, and detect and read newly 
stored/updated information only. This method is different 
from the above described automatic downloading method 
(e) in obtaining information in plural categories by switch- 
ing for each category the functions of the primary storage 

50 center and the secondary storage centers among the central 
computers in a network. 

In this method, the information exchanged among the 
central computers (including software) is handled as ordi- 
nary data. That is, the software currently used by a user is not 

55 directly updated or managed through mirroring, 
(g) Remote Maintenance over a Network 

If a fault occurs in a user computer, a software (or 
hardware) vendor directly operates user software through a 
network at a user's request (or through automatic commu- 

60 nications over the network) to detect the reason for the fault 
and recover from the fault. 

This process is normally performed as a service individu- 
ally provided by a vendor engineer to recover from a 
software fault. 

65 That is, the process is different from an automatic supply 
of maintenance and update services by automatic software 
for a number of users. 
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(h) Client/Server Method 

The client/server method, in which information is com- 
municated between the client and server software and a 
client operates server software, is well known and has been 
used to realize the above listed technologies (b)-(i). No 
systems, however, have been developed so far with this 
method to automatically update software already distributed 
to a user, by simply updating the software in the vendor 
computer. 

Generally, computer software has been designed as an 
advanced, complicated, and large-scale product with wide 
variation, and is used by the increasing number of users in 
various fields. 

Under such conditions, optimally maintaining, managing, 
updating, and improving user computer software is a big 
consuming job to vendors and users. 

Nevertheless, according to the above listed conventional 
methods, the software update information is distributed 
individually by a vendor to a user as in the cases of (a) and 
(b), or is obtained by the user as in the cases of (c) and (d). 
It is determined individually either by a vendor or by a user 
which version or part of software is transmitted and 
obtained, and the software is manually installed or 
re-installed. These manual operations cause many inconve- 
niences and problems. 

From a viewpoint of vendors, since software is supplied 
to a large number of users on a variety of time schedule and 
is independently managed by users, it brings forth various 
problems when the software should be optimally maintained 
and managed. 

That is, the following problems are caused in the above 
listed prior art technologies. 

<Problem 1> Since a great number of users obtain and use 
software with different configurations according to different 
schedules, it is very difficult for vendors to correctly recog- 
nize the configuration of the software of each user. 
<Problem 2> Although a bug is detected and the vendor 
software is corrected in a vendor computer, the software in 
a user computer cannot be corrected immediately. Therefore, 
the user faces inconvenience until the incomplete software is 
corrected in a user computer. 

<Problem 3> It takes a long time to provide all users with 
new services such as extended functions, new versions, etc. 
<Problem 4> Since actual users of software cannot be 
sufficiently recognized by a vendor in many cases, the 
vendor cannot send necessary information promptly to the 
users. This problem grows as the users increase in number 
and in variation, especially for commercially distributed 
software. 

<Problem 5> Since a large cost is required when a vendor 
has to visit a user to install software, it is practically 
impossible to install the software in many cases. Whereas 
not all services provided by the vendor for the software can 
be realized when the user is made responsible to install the 
software. 

From a viewpoint of users, a quick and proper service 
cannot be given by the vendor, and a time-consuming 
process is required onto the user to install, update, or manage 
the software. Thus, the software cannot be sufficiently 
utilized. 

<Problem 6> Sufficient knowledge and time consuming 
work are required to optimally install software depending on 
the hardware/software environment of each user and to 
manage the versions of the installed software, thereby per- 
mitting only skilled engineer to perform the required pro- 

<Problem 7> If software contains bugs, an object job cannot 
be performed properly or smoothly in a user computer, and 
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the user must obtain a bug-corrected version from the 
vendor and install it with taking a long time for the process. 
<Problem 8> Even when new functions are added or new 
versions are developed by the vendor, they are not signifi- 
5 cant until the users can obtain and re-install them success- 
fully, obviously, long processes and time are required to 
obtain and re-install them. 

<Problem 9> Users are often ignorant of the information of 
bug correction, function addition, new version development, 
10 etc. pertaining their software and are using the old software 
as being incomplete. 

<Problem 10> It is troublesome for a user to frequently 
receive information from the software vendor about bug 
correction, additional functions, etc. and to have to install 

15 additional technologies. 

Summing up the above listed problems, they are caused 
by manual processes performed by software vendors or 
users in distributing/obtaining software update information 
(and updated software) and updating the software in the 

20 users' computers (re-installing the software). 

A comparatively simple system to solve these problems 
can be a system of automatically updating an object software 
in a computer of each user to the latest version by use of a 
client/server method A single object program is managed by 

25 client programs in a number of user computers and is 
supported by a server program which manages the software 
library of the object software in a vendor computer. 

However, such a system cannot be successfully designed 
without solving the following various problems of wide- 

30 purpose and wide-variation software of late. 

<Problem 11> A number of users refer to wide variation. For 
example, (1) various computers, (2) various software envi- 
ronments in user computers, (3) various electronic skill 
levels of users, (4) various skill levels and purposes of use 

35 for an object software, (5) various uses of user computers 
(for office use, personal use, etc.), and the like. 

Considering the above listed variation, client programs 
must have sufficient variety in the process to manage soft- 
ware in user computers. Software vendors and server pro- 

40 grams in vendor computers should properly recognize the 
above listed variation at users'. 

<Problem 12> The variation pertaining to a number of 
software affects the distribution and management of the 
software. 

45 There are various types of software which differ in 
distribution and usage. For example, (1) product software, 
published common-use software, and intra-office software, 
(2) embedded software, basic software (OS), and application 
software, (3) operating system, online software, and batch 

50 run software, (4) load module provided, object module 
provided, and source provided software. Each type of soft- 
ware should be processed appropriately. 
<Problem 13> Even a single user has different levels and 
phases in using a single object software. 

55 For example, there are different levels or phases of usage 
as follows: (1) a phase having no purchase right, and a phase 
having an purchase right, (2) a phase of without initial 
installation and a phase complete initial installation, (3) 
beginner user phase, stable user phase, and advanced user 

60 phase, (4) conventional version phase, version switching 
phase, new version phase, (5) a phase of stable use of 
conventional environment, a phase of trial use of new 
environment, and new environment phase, etc. 

These phase differences should be sufficiently considered 

65 for each user to obtain software services properly. 

<Problem 14> A single user usually adopts plural sets of 
object software provided by different vendors. It is not 
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convenient for users that plural sets of object software are 
managed by different distribution/maintenance systems pro- 
vided by different vendors. A more systematic and conve- 
nient system is required by users. 

Summarizing the above problems 11 through 14, a unified 5 
system and method for distributing and maintaining soft- 
ware are required where a number of various software users 
and a number of vendors can systematically manage the 
distribution and maintenance of plural sets of various object 
software. 10 

SUMMARY OF THE INVENTION 

Object of the Invention 

The present invention has been developed to solve the 15 
above described problems of the prior art technologies. 

The first object of the present invention is to provide a 
software distribution/maintenance system and method over 
a network so that a number of various software vendors and 
users can systematically manage plural sets of various object 
software. 

The second object of the present invention is to provide a 
software distribution/maintenance system and method over 
a network so that users can quickly and properly obtain and 2S 
use the software developed and updated by the software 
vendor. 

The third object of the present invention is to provide a 
software distribution/maintenance system and method over 
a network so that computer users connected to the network 30 
can quickly and properly obtain software used by another 
user in the network. 

The fourth object of the present invention is to provide a 
software distribution/maintenance system and method over 
a network so that users can make requests and inquiries to 35 
software suppliers in various formats, for example, inquiries 
of the outline of software, requests for initial purchase of 
software, inquiries of update, request for new services, etc. 

The fifth object of the present invention is to provide a 
software distribution/maintenance system and method over 40 
a network in order to distribute and maintain various types 
of software such as product software, shareware, freeware, 
scientific prototype software, intra-office software, etc. 

The sixth object of the present invention is to provide a 
software distribution/maintenance system and method over 45 
a network so that even an unskilled user can obtain a new 
software or an updated software in an immediately operable 
form. 

The seventh object of the present invention is to provide 5Q 
a software distribution/maintenance system and method 
over a network so that a software vendor can immediately 
detect an occurrence of a software fault in order to quickly 
correct the fault. 

The eighth object of the present invention is to provide a 55 
software distribution/maintenance system and method over 
a network which allows to unify a program of managing the 
software of user computers and to unify a program of 
managing each software library of vendor computers. 

The ninth object of the present invention is to provide a 60 
software distribution/maintenance system and method over 
a network which allows flexible message communication 
between users and vendors by introducing procedure defi- 
nition of methods of processing the messages. 

The tenth object of the present invention is to provide a 65 
software distribution/maintenance system and method over 
a network which allows secured message communication 
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between users and vendors by introducing procedure defi- 
nition of methods of confirming a vendor and determining 
the qualification of a user. 

The eleventh object of the present invention is to provide 
software on a worldwide scale, or build a standardized 
technical framework suitable for a form of software distri- 
bution without making the designs of the client program CP 
and the server program SP complicated. That is, the present 
invention is intended to provide a software distribution and 
maintenance system and method, which uses a number of 
and a variety of pieces of software as objects and can be 
utilized by a number of software users joined on a world- 
wide scale, comprises a capability to rapidly and properly 
acquire and use software created and updated by software 
vendor. 

A feature of the present invention resides in a software 
distribution/maintenance system having a plurality of user 
computers and a vendor computer connected to the plurality 
of user computers through a network to manage and auto- 
matically update over the network a set of object software 
sent and stored in the user computers from the vendor 
computer through the network, comprising: first process 
means in the user computers; second process means in the 
vendor computer; and object software library in the vendor 
computer, wherein said first process means sends current 
configuration information of the object software stored in 
the user computers to said second process means of the 
vendor computer through the network to inquire the latest 
configuration, receives an answer from said second process 
means, and updates the object software stored in the user 
computers according to an instruction in a received answer; 
and 

said second process means receives an inquiry from said 
first process means in the user computers, generates update 
instruction information for the object software to match a 
configuration of the object software in the user computers 
with the configuration of an updated version in said object 
software library stored in the vendor computer, and returns 
through the network to the first process means the update 
instruction information and the software of the updated 
version. 

Another feature of the present invention resides in a 
software distribution/maintenance system having a plurality 
of user computers and a vendor computer to manage and 
automatically update object software provided for the plu- 
rality of user computers from the vendor computer thorough 
a network, comprising: first process means in each of the 
user computers; and 

network means for connecting the user computers to the 
vendor computers; wherein said first process means sends 
current configuration information of the object software 
stored in the user computers to the vendor computer through 
the network to inquire the latest configuration, receives an 
answer from the vendor computer, and updates the object 
software stored in the user computers according to an 
instruction in a received answer. 

A further feature of the present invention resides in a 
software distribution and maintenance system using a net- 
work in which a number of users Ul, U2, . . . using a number 
of types of object software to be distributed, managed, and 
maintained, and a number of software vendors VI , V2, . . . 
supplying the object software manage the distribution and 
maintenance of the object software over a computer 
network, comprising: one or more first process means CPs 
installed in each of user computers, that manage object 
software groups SI, S2, ... to be used by one of more users 
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Ul, U2, . . . individually for every object software and for 
every user; one or more second process means SPs installed 
in either of software vendor computers, that gives services 
to vendor software libraries SL (SI), SL (S2), ... for each 
of the software libraries; a network that connects the first 
process means CP installed in the user computer to the 
second process means SP, based on standardized communi- 
cations protocols; and wherein said first process means CP 
has a capability that perform distribution and/or mainte- 
nance of the object software by sending a message that 
requests to distribute and/or maintain the object software for 
one piece of object software over the network, according to 
instructions given by the users Ul, U2, ... or a user-defined 
program, receiving an answer message from the second 
process means SP, and processing it depending on contents 
of the answer message and settings made by the users Ul, 
U2, . . . ; and said second process means SP has a capability 
to receive the message from an arbitrary first process means 
CP, to reference the software libraries SL(S1), SL(S2), . . . 
managed by the vendors VI, V2, . . . depending on the 
contents of a received message and settings made by the 
vendors VI, V2, ... for the object software specified with 
the message, to generate an answer message to answer the 
request of distribution and/or maintenance of the object 
software, and to send the answer message to said first 
process means CP of the sender of the corresponding mes- 
sage. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows the principle of the first embodiment of the 
present invention; 

FIG. 2 shows the principle of the second embodiment of 
the present invention; 

FIG. 3 shows the system configuration according to the 
first embodiment; 

FIG. 4 shows the process performed by a user computer 
according to the first embodiment; 

FIG. 5 shows the process performed by a server program 
of a vendor computer according to the first embodiment; 

FIG. 6 shows the process for periodical update in a user 
computer according to the first embodiment; 

FIG. 7 shows a practical example of the first embodiment; 

FIG. 8 shows the system configuration according to the 
second embodiment; 

FIG. 9 shows the computer as a vendor-and-user com- 
puter according to the second embodiment; 

FIG. 10 shows the contents of user management data in a 
user computer according to the second embodiment; 

FIG. 11 shows the contents of the vendor management 
data in a vendor computer according to the second embodi- 
ment. 

FIG. 12 shows the entire configuration of the process 
performed by a client program according to the second 
embodiment; 

FIG. 13 shows the entire configuration (continued) of the 
process performed by a client program according to the 
second embodiment; 

FIG. 14 shows the entire configuration of the process 
performed by a server program according to the second 
embodiment; 

FIG. 15 shows the entire configuration (continued) of the 
process performed by a server program according to the 
second embodiment; 

FIG. 16 is a flowchart showing the entire process of the 
software distribution/maintenance method according to the 
second embodiment; 
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FIG. 17 is a flowchart showing the entire process per- 
formed by the software distribution/maintenance method 
using user management data and vendor management data; 

FIG. 18 shows a block diagram of a principle structure 
5 according to the third embodiment of the present invention; 

FIG. 19 shows a block diagram of the third embodiment 
shown in FIG. 18 of a software distribution and maintenance 
system utilizing a network according to the present inven- 
tion; 

FIG. 20 designates an upward message and a downward 
message according to the third embodiment; 

FIG. 21 depicts an example of a processing command; 

FIG. 22 shows the correspondence relationship between 
15 various messages; 

FIG. 23 shows a flowchart of an entire process performed 
by a client program CP according to the third embodiment; 

FIG. 24 shows a flowchart of an entire process performed 
20 by a server program SP according to the third embodiment. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 
First Preferred Embodiment for Distributing/Maintaining an 

25 Object Software 

According to the first embodiment of the present 
invention, a client program is stored in each user computer 
to manage an object software to be distributed and 
maintained, and a server program is stored in a vendor 

30 computer to manage an object software library. 

The client program sends configuration information indi- 
cating the modules forming the object software in the user 
computer to the server program of the vendor computer 
through the network, inquires whether or not the configu- 

35 ration of the present object software matches the configu- 
ration of the latest configuration, receives an answer from 
the server program, and updates the object software accord- 
ing to the answer. 

On the other hand, the server program receives an inquiry 

40 about the configuration of software from any client program 
in a plurality of user computers, generates update instruction 
information for the object software so that the configuration 
of the user software matches the latest version of the object 
software in the vendor computer, and answers the inquiring 

45 client program, by providing the update instruction infor- 
mation and the software of the latest version over the 
network. 

Second Preferred Embodiment for Distributing/ Maintaining 
Multiple Object Software of Multiple Vendors 

50 The above described configuration is used in an automatic 
remote software update system in which a single object 
software is used as a principle. Furthermore, according to 
the second embodiment, each user computer is usually 
provided with plural sets of object software, and each vendor 

55 computer is usually provided with a plurality of software 
libraries. 

According to the second embodiment, each user computer 
stores a client program for managing plural sets of software 
used by a plurality of users, and each vendor computer stores 

60 a server program for managing a plurality of software 
libraries provided by the vendor. 

The client program in each user computer sends according 
to the instruction of the user over a network a message 
requesting to distribute/maintain a single object software to 

65 the server program in the vendor computer from which the 
software is supplied, and then performs processes to distrib- 
ute and maintain the object software according to the answer 



5,82 

9 

message from the server program and the answer instruction 
predetermined by the user. 

In response to this, when the server program receives a 
message from the client program in any user computer, it 
refers to the software library of the object software specified 
by the message according to the received message and the 
received instruction predetermined by the vendor, generates 
an answer message to the distribution/maintenance request 
message, and returns the answer message to the client 
program over the network. 

According to the present invention, the server program in 
the vendor computer returns the answer message in response 
to the software distribution/maintenance request message 
from the client program, thereby automatically distributing/ 
maintaining the object software as described above. 
Explanation of the Principle 

Explanation of the Principle of the First Embodiment 

Described first is the principle of the first embodiment of 
the present invention. 

FIG. 1 shows the principle of the first embodiment. In 
FIG. 1, user computers 1-1, . . . , 1-n are connected to a 
vendor computer 3. Each of the user computers 1-1, . . . , 1-n 
is equipped with an object software la to be updated/ 
managed and a first process unit lb (which may be called a 
client program CP) for managing the configuration and 
operation of is the object software la, for example. A user 
can perform a necessary job by operating the object software 
la. 

3 is a vendor computer. The vendor computer 3 is 
provided with a second process unit 3a (which may be called 
a server program SP) for managing the object software la 
stored in the user computers 1-1, . . . , 1-n, and an object 
software library 3b. 

To solve the above described problems, a software 
distribution/maintenance system according to the present 
invention comprises, as shown in FIG. 1, a plurality of the 
user computers 1-1, . . . , 1-n and the vendor computer 3 
connected to the plurality of user computers 1-1, . . . , 1-n 
through the network 2, and manages and automatically 
updates over a network the object software la stored in the 
user computers 1-1, ... 1-n from the vendor computer 3 
through the network 2. 

In this system, the user computers 1-1, . . . , 1-n comprise 
the first process units lb, and the vendor computer 3 
comprises the second process unit 3a and the object software 
library 3b. 

The first process unit lb sends the current configuration 
information of the object software la stored in the user 

computers 1-1 1-n to the second process unit 3a of the 

vendor computer 3 through the network 2 to inquire the 
latest configuration, receives an answer from the second 
process unit 3a, and updates the object software la stored in 
the user computers 1-1, . . . , 1-n according to the instruction 
in the received answer. The second process unit 3a receives 
the inquiry from any of the first process units lb stored in the 
user computers 1-1, . . . , 1-n, generates update instruction 
information for the object software la to match the con- 
figuration of the object software la in the user computers 
1-1, . . . , 1-n with the configuration of the updated version 
in the object software library 3b stored in the vendor 
computer 3, and returns through the network 2 to the 
inquiring first process unit lb the update instruction infor- 
mation and the software of the updated version. 

Furthermore, according to the present invention, if the 
operation of the object software la abnormally terminates in 
the user computers 1-1, . . . , 1-n, the first process units lb 
in the user computers 1-1, ... 1-n automatically inform over 
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the network 2 the vendor computer 3 of an abnormal 
termination and its state. 

The first process unit lb according to the present inven- 
tion automatically informs the vendor computer 3 of the 

5 abnormal termination, the instruction causing the abnormal 
termination and the reason for the abnormal termination, a 
series of instructions which invoked the instruction causing 
the abnormal termination, and the environment of the 
software/hardware used when the abnormal termination is 

10 detected. 

The first process unit lb can be designed to automatically 
informs over the network 2 the vendor computer 3 of the fact 
and state of the termination of an abnormal condition by 
general-purpose electronic mail. 
15 According to the present invention, the software 
distribution/maintenance method manages and automati- 
cally updates the object software la stared in the user 
computers 1-1, . . . , 1-n from the vendor computer 3 through 
network 2 . 

20 In this method, the first process units lb in the user 
computers 1-1, . . . , 1-n send the current configuration 
information of the object software la to the second process 
unit 3a in the vendor computer 3 through the network 2 to 
inquire the latest configuration. 

25 The second process unit 3a in the vendor computer 3 
receives the above described inquiry, generates update 
instruction information for the object software la to match 
the configuration of the object software la in the user 
computers 1-1, . . . , 1-n with the configuration of the 

30 updated version in the object software library 3b stored in 
the vendor computer 3, and returns through the network 2 to 
the inquiring first process unit lb the update instruction 
information and the software of the updated version. 
The first process units lb stored in the user computers 

35 1-1, . . . , 1-n receive an answer from the second process unit 
3a, update the object software la according to the update 
instruction information in the answer, and prepare for the 
compiling and linking of programs if necessary. 

There can be plural ways of activating the first process 

40 unit lb. Three ways of them are shown below: 

When the object software la is activated in the user 
computers 1-1, . . . , 1-n, the first process unit lb immedi- 
ately sends the current configuration information of the 
object software la to the second process unit 3a in the 

45 vendor computer 3 through the network 2 to inquire the 
latest configuration, receives an answer from the second 
process unit 3a, updates the object software la according to 
the update instruction information in the answer, and pre- 
pares is for the compiling and linking of programs if 

50 necessary. 

When the first process unit lb is activated in the user 

computers 1-1 1-n at a predetermined time, the first 

process unit lb sends the current configuration information 
of the object software la to the second process unit 3a in the 

55 vendor computer 3 through the network 2 to inquire the 
latest configuration, receives an answer from the second 
process unit 3a, updates the object software la according to 
the update instruction information in the answer, and pre- 
pares for the compiling and linking of programs if necessary. 

60 Thus, the object software la can be automatically updated. 
When a user instructs the user computers 1-1, . . . 1-n to 
activate the first process unit lb, the first process unit lb 
sends the current configuration information of the object 
software la to the second process unit 3a in the vendor 

65 computer 3 through the network 2 to inquire the latest 
configuration, receives an answer from the second process 
unit 3a, updates the object software la according to the 



5,835,911 

11 12 

update instruction information in the answer, and prepares the object software library 3b, and returns through the 

for the compiling and linking of programs if necessary. network 2 to the inquiring first process unit lb the update 

Thus, the object software la can be automatically updated. instruction information and the software of the updated 

The above described methods can be selectively used to version. The first process unit lb receives an answer from 

activate the first process unit lb. 5 the second process unit 3a, updates the object software la 

Function of the First Embodiment of the Present Invention according to the update instruction information in the 

In FIG. 1, if a user activates the object software la of the answer, and prepares for the compiling and linking of 

user computers 1-1, . . . , 1-n, then the first process unit lb programs if necessary. 

detects the activation and sends configuration information of When the object software la is activated, the first process 

the current version to the second process unit 3a in the 10 unit lb immediately sends the current configuration infor- 

vendor computer 3 through the network 2. When the second mation of the object software la to the second process unit 

process unit 3a in the vendor computer 3 receives the 3a in the vendor computer 3 through the network 2 to inquire 

information, it compares the current configuration with the the latest configuration, receives an answer from the second 

configuration stored in the object software library 3b, and process unit 3a, updates the object software la according to 

returns the instruction information for the update of the is the update instruction information in the answer, and pre- 

object software la of the user together with the update pares for the compiling and linking of programs if necessary, 

software. The user's first process unit lb automatically Thus, the user can automatically update the object software 

updates the object software la using the received informa- la without considering the activation of the first process unit 

The first process unit lb can be activated at a predeter- 20 When the first process unit lb is activated at a predeter- 
mined time or at a user instruction as shown in FIG. 1, mined time, the first process unit lb sends the current 
thereby updating the object software la. configuration information of the object is software la to the 

Thus, the current configurations of the software in the second process unit 3a to inquire the latest configuration, 

computers of a number of users can be exactly recognized by receives an answer from the second process unit 3a, updates 

the vendor, and the vendor can automatically provide the 25 the object software la according to the update instruction 

users with the latest version of the software and the latest information in the answer, and prepares for the compiling 

information relating to the software. and linking of programs if necessary. Thus, the object 

Furthermore, the software can be automatically installed software la can be automatically updated. Therefore, the 

and the latest version of the software can also be automati- object software la can be automatically updated at night, for 

cally managed. Therefore, the vendor does not have to visit 30 example, with the user released of being kept waiting in 

the user's office to install the software, and even beginners updating the object software la during the operation of the 

and unskilled users can correctly receive the latest version of software. Furthermore, by the activation of the first process 

the software. unit lb at times predetermined by user's software, the object 

In case that the operation of the object software la software la can be automatically updated periodically every 

abnormally terminates in the user computers 1-1 1-n, 35 dawn, every week, or every month without user's explicit 

the first process units lb in the user computers 1-1, . . . , 1-n operations. 

automatically inform over the network 2 the vendor com- When the user explicitly activates the first process unit lb, 

puter 3 of an abnormal termination and its state if the it immediately sends the current configuration information 

operation of the object software la abnormally terminates in of the object software la to the second process unit 3a in the 

the user computers 1-1 1-n. Therefore, the user system 40 vendor computer 3 through the network 2 to inquire the 

automatically informs the vendor of the exact information of latest configuration, receives an answer from the second 

a fault of the software in the user computer when it occurs. process unit 3a, updates the object software la according to 

The vendor corrects the software library according to the the update instruction information in the answer, and pre- 

fault information. Then, the user can immediately use or pares for the compiling and linking of programs if necessary, 

operate the corrected software without a burden on the user. 45 Thus, the object software can be automatically updated by 

The first process unit lb automatically informs the vendor the user's initiation at any time when necessary, 

computer 3 of the abnormal termination, the instruction The above described methods can be selectively used to 

causing the abnormal termination and the reason for the update the object software la. 

abnormal termination, a series of instructions which invoked Explanation of the Principle of the Second Embodiment 

the instruction causing the abnormal termination, and the 50 Described below is the principle of the second embodi- 

environment of the software/hardware used when the abnor- ment. According to the second embodiment, unlike the first 

mal termination is detected. Accordingly, the vendor can embodiment, each user computer normally comprises plural 

efficiently correct the object software according to the above sets of software which are used by each user and provided 

described detailed fault information. The first process unit by a plurality of vendors, and a plurality of vendor comput- 

lb automatically informs the vendor computer 3 of an 55 ers store a plurality of software libraries, 

abnormal termination and state over the network 2 in the General Structure of the System 

format of general-purpose electronic mail, thereby transmit- FIG. 2 shows the principle of the second embodiment. In 

ting the abnormal termination information and the state in FIG. 2, a user computer 11 is used by a plurality of users Ul, 

the common communications. U2, . . . (normally represented as user Uj). The users are 

The first process unit lb sends the current configuration 60 provided with object software SU1, SU2, . . . (normally 

information of the object software la to the second process represented as object software SUj) to be managed by the 

unit la in the vendor computer 3 through the network 2 to present invention, user management data UD1, UD2, . . . 

inquire the latest configuration. The second process unit 3a (normally represented as management data UDj), and a third 

in the vendor computer 3 receives the above described process unit GP, for example, a client program, 

inquiry, generates update instruction information for the 65 The third process unit CP sends to a vendor various 

object software la to match the configuration of the object messages from a user to the vendor such as software 

software la with the configuration of the updated version in purchase requests, update inquiries, fault reports, etc., 
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receives an answer from the vendor, updates user software, plural sets of software (supplied by different vendors), but 

etc. The user management data UD1, UD2, . . . contain user usually a single version for each set. Thus, the second 

identification information, software management/ embodiment is based on the supply/use of plural sets of 

configuration information, information (procedure) for regu- software from a number of vendors to a number of users, 

lating a processing method (method of installing software), 5 As shown in FIG. 2, the distribution of object software is 

etc. The information is used when various messages such as managed over the communications network 2 by a number 

software purchase requests, update inquiries, fault reports, of users Ul, U2, . . . who actually use plural sets of object 

etc. are issued by the third process unit CP and when the user software SI, S2, . . . to be distributed, managed, and 

software is updated. maintained and by a number of software vendors VI, V2, . 

A vendor computer 13 is provided with software libraries 10 . . who supply the users with the above listed object software 

SL1, SL2 (normally represented as SLi) of a vendor VI in the software distribution/maintenance system according 

(normally represented as a vendor Vk), vendor management to the present invention. The system comprises the following 

data VD1, VD2 (normally represented by VDi), and a fourth units. 

process unit SP, for example, a server program. (a) In each user computer 11, object software SU1, SU2, . . . 

The fourth process unit SP returns necessary information 15 to be used by users Ul, U2, . . . , and a third process unit CP 

and software in response to various inquiries and requests for managing plural sets of object software SU1, SU2, .... 

from the users Ul, U2, (b) In each software vendor computer 13, vendor software 

The vendor management data VDI, VD2 contain data libraries SLI, SL2, . . . and a fourth process unit SP for 

such as vendor identification information, software configu- providing services relating to the software libraries SLI, 

ration information, customer management information, etc.; 20 SL2, .... 

and regulatory information (procedure) for defining an (c) a network 12 for connecting each user computer 11 and 

answering method. vendor computer 13 

A user/vendor computer 14 is used by a user U3 and a Each unit has the following functions, 

vendor V2 (or a user can be a vendor) and they are (d) The third process unit CP sends over the network 12 an 

individually provided with object software SU3, user man- 25 object software distribution and/or maintenance request 

agement data UD3, the third process units CP, software message according to an instruction of users Ul, U2, ... or 

libraries SLn, vendor management data VDn, and the fourth an instruction of a user-written program to the fourth process 

process units SP. unit SP of the vendor computer 13 which stores a software 

A network 12 connects the above mentioned computers library containing the above described object software, 

11, 13, and 14, and transmits messages communicated 30 receives an answer message from the fourth process unit SP, 

among them. and performs processes for distributing and/or maintaining 

The configurations and versions of an object software are the object software, 

represented using the following terms and identification (e) The fourth process unit SP receives the message from any 

characters in this specification. third process unit CP, refers to software libraries SLI, 

Each object software is referred to as object software Si. 35 SL2, . . . managed by vendors VI, V2, . . . according to the 

For example, SI and S2 are different software. Since a single received message and the settings made by vendors VI, 

set of software Si has a number of version types depending V2, . . . , generates an answer message in response to the 

on the type of computer, the specification of functions, etc., object software distribution and/or maintenance request 

the version types are specified by respective characters such message, and sends the answer message to the third process 

as Si.V, Si.V, Si.V", etc. Furthermore, each version type is 40 unit CP of the message sender. 

qualified with a version number for management of update When any object software managed by the third process 

order. For example, Si.V.l indicates the version type and unit CP in the user computer 11 abnormally terminates 

number of a set of software. The set of version type and during its operation, the third process unit CP detects and 

number are referred to as a version for short. analyzes the abnormal condition, and then automatically 

The object software Si is supplied by a vendor (Vk) and 45 sends the fault report to the fourth process unit SP of vendors 

managed in the software library SLi which stores software VI, V2, . . . over the network 12. The fourth process unit SP 

of all versions (Si.V.l, Si.V.2, . . . Si.V.l, . . . ) of all version of vendors VI, V2, . . . receives the fault report and informs 

types Si.V, Si.V, . . . Each object software Si normally vendors VI, V2, . . . of the fault. 

comprises a number of modules Ml, M2, . . . (Commonly When each version of the object software is provided for 
represented by Mm), and each of these modules is also 50 a number of users Ul, U2, ... by vendors VI, V2, . . . , a 
assigned a new version number each time the module is single computer user can be user Uj of a version of software 
updated. Thus, a module is represented by a module type and and at the same time vendor Vk of a version of another 
version number, for example, Mm.n. Generally, a software software, and furthermore, a single computer can be pro- 
version Si.V.l of software Si comprises a number of versions vided with one or more third process units CP and one or 
of modules (for example, M1.2, M2.1, M3.5, . . . ), and a 55 more fourth process units SP. 

specific module version can be shared by different software Each user computer 11 can be designed to store user 

versions. management data UD1, UD2, ... for each of users Ul, 

When users adopt object software Si, they normally desire U2, ... or each user group, and the data can be set for each 

to select the optimum version type Si.V from among a object software. The third process unit CP refers to user 

number of version types and then use the latest version 60 management data UD1, UD2, ... to manage one or more 

51. VI in the selected type. sets of object software SU1, SU2, . . . 

Usually, a single user uses plural sets of software. Plural User management data UD1, UD2, ... can be designed 

sets of object software SUj used by user Uj comprise a to comprise user identification information of each user Ul, 

number of versions of software (for example, Si.V.l, U2, ... or each user group, software management informa- 

52. V.3, S3.V.1, . . . ). 65 tion of each object software used by each user Ul, U2, . . . , 
As described above, a vendor manages a number of software configuration information, and message process 

i single set of software, and a user manipulates method specification information. 
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In specifying a method of processing a message according 
to user management data UD1, UD2, . . . , users Ul, U2, . . . 
can specify a process method as a procedure for each 
function performed by the third process unit CP. 

In specifying a method of processing a message according 
to user management data UD1, UD2, . . . , a vendor 
confirmation procedure can be used so that the vendor can 
be confirmed in order to protect the user software. 

When the fourth process unit SP of the vendor computer 
13 offers services using software libraries SL1, SL2 . . . , it 
can refer to vendor management data VD1, VD2 stored for 
each software library SL1, SL2, .... 

Vendor management data VD1, VD2 can be designed to 
comprise the vendor identification information, software 
management information, software configuration 
information, message process method specification 
information, customer information, fault history 
information, etc. 

When a message process method is specified using vendor 
management data VD1, VD2, vendors VI, V2, ... can 
specify a method of the process as a procedure for each 
function performed by the fourth process unit SP. 

When a message process method is specified using vendor 
management data VD1, VD2, a selection of user confirma- 
tion procedure can be implemented. 

Users Ul, U2, . . . can simultaneously obtain and use a 
plurality of versions of each object software. 
General Method of Processing 

The distribution of object software is managed over the 
communications network 2 by a number of users Ul, U2, . . . 
who actually use plural sets of object software SI, S2, . . . 
to be distributed, managed, and maintained and by a number 
of software vendors VI, V2, . . . who supply the users with 
the above listed object software in the software distribution/ 
maintenance system according to the present invention. The 
system comprises, in each user computer 11, object software 
SU1, SU2, ... to be used by users Ul, U2, . . . , and a third 
process unit CP for managing plural sets of object software 
SU1, SU2, . . . ; in each software vendor computer 13, 
vendor software libraries SL1, SL2, . . . and a fourth process 
unit SP for providing services relating to the software 
libraries SL1, SL2, . . . ; and a network 12 for connecting 
each user computer 11 and vendor computer 13. This system 
performs the following processes. 

(a) Users Ul, U2, . . . activate the third process unit CP 
through a command input by users Ul, U2, ... in the user 
computer 11 or according to the activation through a com- 
mand from a user's program. 

(b) Users Ul, U2, . . . send over the network 12 an object 
software distribution and/or maintenance request message to 
the fourth process unit SP of the vendor computer 13 from 
which the object software is provided. 

(c) The fourth process unit SP in the vendor computer 13, 
from which the object software is provided, receives the 
message from the third process unit CP. 

(d) The fourth process unit SP refers to software libraries 
SL1, SL2, . . . managed by vendors VI, V2, . . . according 
to the received message and the settings made by vendors 
VI, V2, . . . , generates an answer message in response to the 
object software distribution and/or maintenance request 
message, and sends the answer message to the third process 
unit CP of the message sender. 

(e) The third process unit CP in the computers of the 
message sending users Ul, U2, . . . receives the answer 
message from the fourth process unit SP, and performs 
processes for distributing and/or maintaining the above 
described object software according to the answer message 
and the settings made by users Ul, U2, .... 
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When any object software managed by the third process 
unit CP in the user computer 11 abnormally terminates 
during its operation, the third process unit CP detects and 
analyzes the abnormal condition, and then sends the fault 

5 report message to the vendor Vk of the software over the 
network 12. The fourth process unit SP of vendors Vk 
receives the fault report message over the network 12, and 
informs the vendor Vk of the fault. 
Management Data and Processing in a User Computer 

10 Each user computer 11 can be designed to store user 
management data UD1, UD2, ... for each of users Ul, 
U2, ... or each user group, and the data can be set for each 
object software. The third process unit CP refers to user 
management data UD1, UD2, ... to manage one or more 

15 sets of object software SU1, SU2, .... 

User management data UDj can be designed to comprise 
at least user identification information of user Uj or each 
user group, software management information of each 
object software SI, S2, . . . in object software group SUj 

20 used by each user Uj software configuration information, 
and message process method specification information. The 
third process unit CP refers to user management data UDj. 

In referring to a method of processing a message accord- 
ing to user management data UDj, user Uj can specify and 

25 use a process method as a procedure for each function 
performed by the third process unit CP. 

In referring to the method of processing a message 
according to user management data UD1, UD2, . . . , a 
user-Uj -defined vendor confirmation procedure can be used 

30 so that the message received by the third process unit CP can 
be recognized as a correct message from the predetermined 
vender Vk. 

When user Uj activates the third process unit CP in the 
user computer 11 by inputting a command, the third process 

35 unit CP obtains a user name, a command name, and an object 
software name to generate an interactive screen displaying 
messages according to the input command, promotes the 
generation of a message in response to the command from 
user Uj by referring to user management data UDj of user Uj 

40 and object software Si or by invoking a user-defined process 
procedure, sends the generated message to the fourth process 
unit SP of the computer of vendors Vk of object software Si, 
and returns to a standby state after recording the transmis- 
sion of the message. 

45 The third process unit CP performs the following pro- 
cesses depending on the cause of the activation of the third 
process unit CP. 

(a) When the third process unit CP is activated in the user 
computer 11 by an input command, the third process unit CP 

50 obtains a user name, a command name, and an object 
software name to generate an interactive screen displaying 
messages according to the input command, promotes the 
generation of a message in response to the command from 
user Uj by referring to user management data UDj of user Uj 

55 and object software Si or by invoking a user-defined process 
procedure, sends the generated message to the fourth process 
unit SP of the computer of vendors Vk of object software Si, 
and returns to a standby state after recording the transmis- 
sion of the message. 

60 (b) If the third process unit CP is activated in the user 
computer 11 by a command from a program defined by user 
Uj or through an abnormal termination of the object soft- 
ware managed by the third process unit CP, the third process 
unit CP obtains a user name, a command name, and an object 

65 software name to, promotes in response to the activated 
command the generation of a message in response to the 
command from user Uj by referring to user management 
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data UDj of user Uj and object software Si or by invoking For example, the network connection in the way of tele- 

a user-defined process procedure, sends the generated mes- phone or the network transmission in the way of mail can be 

sage to the fourth process unit SP of the computer of vendors used properly. 

Vk of object software Si, and returns to a standby state after The header of a message transmitted over the network 12 
recording the transmission of the message. 5 specifies the destination and the source of the message, 
(c) If the third process unit CP is activated in the user Additionally, the title column of the message specifies the 
computer 11 by a message received from the network 12, name of a software distribution/maintenance system, the 
then the third process unit CP obtains from the header of the name ° f a softw ^ e distribution/maintenance process type, 
received message a destination user name, a command andthe name of the object software, 
name, and an object software name, uses user management 10 ^ e f ™th process unit SP m the vendor computer 13 
data UDj for the specified user Uj and object software Si, ^fX-- u™ constantly in a standby 
then obtains a sender name from the header of the revived ^ ^ ^ k receives a ffl J from ^ 
message confirms that the sender is a right vendor Vk of third ss unit cp Qver the QCtWQ± n . 
object software Si, also confirms that the third process unit (b) obtains the command name md the object software name 
CP is in an answer-wait state, refers to user management 15 from the header of the rece i ve d message, and then assigns 
data UDj or invokes the user-defined process procedure the processes to be performed to each software Si; 
depending on the command in the received message, ana- ( c ) obtains the name of the sending user and the user 
lyzes or stores the message data or stores or installs the identification information from the received message corn- 
software specified by the message, returns, in response to a pares it with vendor management data VDi to confirm user 
specific message which requires acknowledgement, the 20 Uj and determine the user Uj's access qualification relating 
acknowledgement or the process in response to the reception to the command, 

to the fourth process unit SP over the network 12, and then (d) analyzes the received message from the qualified user 

returns to a standby state after recording the transmission of Uj; 

the message. (e) in response to the received command, provides summary 

Each time the third process unit CP is activated, a new 25 information of software Si, provides new services for the 

process is generated to allow plural processes to be per- software, supplies the updated software and the instructions 

formed in parallel on the processes other than the process to correctly update the software, retrieves information of 

relating to a specific object software of a specific user. other messages, and generates an answer message; 

Management Data and Processing in a Vendor Computer (f) records the summary of the answer message to user Uj, 

When the fourth process unit SP in the vendor computer 30 and sends the answer message to the third process unit CP 

13 offers services using software libraries SL1, SL2, . . . , of user Uj over the network 12; and 

vendor management data VDi, which is stored in each (g) returns to the standby state. 

software library SLi, is referred to. Each time the fourth process unit SP is activated, a new 

When the fourth process unit SP refers to vendor man- process is generated to allow a plurality of processes to be 

agement data VDi, it refers corresponding to software 35 concurrently performed on the processes other than the 

library SLi to at least the vendor identification information, process relating to a specific object software of a specific 

software management information, software configuration user 

information, message process method specification Distribution and Maintenance Processes 

information, customer information, update history When users Ul, U2, . . . want to obtain the summary 

information, and fault history information. 40 information of the object software not used by them, the 

When a message process method is referred to using following processes are performed, 

vendor management data VDi, vendor Vk can invoke a In the user computer 11; 

method of the process as a procedure for each function (a) User Uj enters a summary inquiry command, activates 

performed by the fourth process unit SP. the third process unit CP in the user computer 11, sets the 

When a message process method is referred to using 45 name of software Si, the name of vendor Vk, the network 

vendor management data VDi, a user confirmation proce- address of the vendor, an answer information storage 

dure can be invoked to confirm the identity of user Uj who directory, etc., and generates a summary information inquiry 

is a sender of the message, determine the qualification of the message. 

user, and return appropriate answer to the user. (b) The third process unit CP sends the generated message 

In the user confirmation procedure as a part of vendor 50 to the fourth process unit SP of the vendor Vk. 

management data VDi, the qualification of a user can be In the vendor computer 13; 

determined based on commercial relations such as contracts (c) The fourth process unit SP is activated when it receives 

relating to the object software, payments relating to the the summary information inquiry message over the network 

object software, payments relating to new services for the 12. 

object software, etc. 55 (d) The fourth process unit SP refers to vendor management 

In the user confirmation procedure as a part of vendor data VDi about object software Si cited by the summary 

management data VDi, the object software can be provided information inquiry message to confirm the identification of 

and distributed only to specified users Ul, U2, ... by the sending user Uj and determine the access qualification of 

referring to their identification information such as the the user; 

organizations to which they belong, their titles, personal 60 (e) invokes, in response to the inquiry of the qualified user 

names, etc. Uj, a vendor-defined procedure to provide the summary 

In the user confirmation procedure as a part of vendor information, and generates the summary information as a 

management data VDI, VD2, . . ., users Ul, U2, . . . can be summary information message; and 

identified by passwords. (f) sends the generated message to the third process unit CP 

The user computer 11 and/or the vendor computer 13 65 of the sending user Uj over the network 12. 

should be connected to the network 12 only when it is When users Ul, U2, . . . newly obtain an object software 

necessary to send or receive messages to or from each other. not used by them, the following processes are performed. 
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In the user computer 11; 

(a) User Uj enters a new installation request command, 
activates the third process unit CP in the user computer 11, 
sets the user identification information, software information 
of object software, vendor identification information, and 
installation process information, and generates a new instal- 
lation request message. 

(b) The third process unit CP sends the generated message 
to the fourth process unit SP of the vendor Vk of software 
Si. 

In the vendor computer 13; 

(c) The fourth process unit SP is activated when it receives 
the new installation request message over the network 12. 

(d) The fourth process unit SP refers to vendor management 
data VDi about object software Si cited by the new instal- 
lation request to confirm the identification of the sending 
user Uj and determine the access qualification of the user; 

(e) invokes, in response to the inquiry of the qualified user 
Uj, a vendor-defined procedure for the new installation to 
determine a version Si.V.l to be provided, obtains a set of 
modules of the provided version, organizes the instruction 
information of the installation in the user computer 11, and 
generates a new installation message as an answer, and 

(f) sends the generated new installation message as an 
answer to the third process unit CP of the sending user Uj 
over the network 12. 

In the user computer 11; 

(g) The third process unit CP is activated when it receives a 
new installation message from vendor Vk over the network 
12. 

(h) The third process unit CP obtains the name of a desti- 
nation user and the name of an object software from the 
header of the received message, refers to the corresponding 
user management data UDj, and confirms that the third 
process unit CP is currently in a new installation standby 
state and that the sender is a correct vendor Vk; 

(i) invokes a user-defined new installation process 
procedure, refers to the installation information in the 
received message, stores the software Si to be newly 
installed in the user computer 11, and actually installs the 
newly supplied software if the new installation is acceptable; 

(j) records the received message and the process result, and 
returns to a standby state. 

When users Ul, U2, . . . add or switch to a new service 
of an object software already used by them, the following 
processes are performed. 

In the user computer 11; 

(a) User Uj enters a new service request command, activates 
the third process unit CP in the user computer 11, sets the 
user identification information, software information of 
object software, vendor identification information, and 
installation process information, and generates a new service 
request message. 

(b) The third process unit CP sends the generated message 
to the fourth process unit SP of the vendor vk. 

In the vendor computer 13; 

(c) The fourth process unit SP is activated when it receives 
the new service request message over the network 12. 

(d) The fourth process unit SP refers to vendor management 
data VDi about object software Si cited by the new service 
request to confirm the identification of the sending user Uj 
and determine the access qualification of the user; 

(e) invokes, in response to the inquiry of the qualified user 
Uj, a vendor-defined procedure for the supply of the new 
service to determine a version Si.V.l to be provided, obtains 
a set of modules of the provided version, organizes the 
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instruction information of the installation in the user com- 
puter 11, specifies a process performed on the old service, 
and generates a new installation message as an answer, and 

(f) sends the generated new service supply message as an 
5 answer to the third process unit CP of the sending user Uj 

over the network 12. 
In the user computer 11; 

(g) The third process unit CP is activated when it receives a 
new service installation message from vendor Vk over the 
network 12. 

(h) The third process unit CP obtains the name of a desti- 
nation user and the name of an object software from the 
header of the received message, refers to the corresponding 
user management data UDj, and confirms that the third 
process unit CP is currently in a new service installation 

15 standby state and that the sender is a correct vendor Vk; 

(i) invokes a user-defined process procedure, refers to the 
installation information in the received message, stores the 
software Si supplied as a new service in the user computer 
11, and actually stores the new service of the software if the 

20 new service is acceptable; and 

(j) records the received message and the process result, and 
returns to a standby state. 

When users Ul, U2, . . . inquire the update state of an 
object software already used by them of vendors VI, V2, . 
25 . . and request to send an updated software, the following 
processes are performed. 
In the user computer 11; 

(a) User Uj enters an update inquiry command, activates the 
third process unit CP in the user computer 11, sets the user 
identification information, software information of object 
software, vendor identification information, software man- 
agement information, and post-installation process 
information, and generates an update inquiry message. 

(b) The third process unit CP sends the generated message 
to the fourth process unit SP of the vendor Vk of software 

35 Si. 

In the vendor computer 13; 

(c) The fourth process unit SP is activated when it receives 
the update inquiry message over the network 12. 

(d) The fourth process unit SP refers to vendor management 
40 data VDi about object software Si cited by the update 

inquiry to confirm the identification of the sending user Uj 
and determine the access qualification of the user; 

(e) invokes, in response to the inquiry of the qualified user 
Uj, a vendor-defined update inquiry answering procedure to 

45 determine the version type Si.V to be supplied and the latest 
version Si.V.l, and compares it with the current version of 

(f) if the current version of user Uj matches the latest 
version, then generates a non-update answer message, sends 

50 it to the third process unit CP of the inquiring user Uj; 

(g) if object software Si.V of the same version type as the 
current version of user Uj has been updated, then module 
delete/add instruction information and information about 
modules to be added are generated as an update instruction 

55 message as an answer, and the generated answer is sent to 
the third process unit CP of the inquiring user Uj over the 
network 12; and 

(h) if it is determined that the current version should be 
switched to a newly served version of object software Si, 

60 then generates a non-update and information message about 
a newly served version Si.V, and sends the generated 
information message to the third process unit CP of the 
inquiring user Uj over the network 12. 
In the user computer 11; 

65 (i) The third process unit CP is activated when it receives an 
update instruction message or a non-update message from 
vendor Vk over the network 12. 
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(j) The third process unit CP obtains the name of a desti- 
nation user and the name of an object software from the 
header of the received message, refers to the corresponding 
user management data UDj, and confirms that the third 
process unit CP is currently in a standby state after inquiry 
and that the sender is a correct vendor Vk; 
(k) if it receives a non-update message, records the received 
message and the process result, and returns to a standby 

(1) if it receives an update instruction message, invokes a 
user-defined update reception process procedure, refers to 
the update instruction information in the received message, 
stores in the user computer 11 the software specified by the 
update instruction message, and actually installs the soft- 
ware if the specified software is acceptable; and 
(m) records the received message and the process result, and 
returns to a standby state. 

When users Ul, U2, . . . inquire the update state of an 
object software already used by them of vendors VI, V2, . . . 
and request to send an updated software, the following 
processes are performed. 

In the user computer 11; 

(a) the third process unit CP in the user computer 11 is 
activated according to the update inquiry command instruc- 
tion of a user's program, invokes an automatically-editing 
update inquiry procedure, refers to user management data 
UDj, and generates an update inquiry message. 

(b) The third process unit CP sends the generated message 
to the fourth process unit SP of the vendor Vk of software 
Si. 

In the vendor computer 13; 

(c) The fourth process unit SP is activated when it receives 
the update inquiry message over the network 12. 

(d) The fourth process unit SP refers to vendor management 
data VDi about object software Si cited by the update 
inquiry to confirm the identification of the sending user Uj 
and determine the access qualification of the user; 

(e) invokes, in response to the inquiry of the qualified user 
Uj, a update inquiry answering procedure to determine the 
version type Si. V to be supplied and its latest version Si. VI, 
and compares it with user Uj 's current version; 

(f) if the current version of user Uj matches the latest 
version, then generates a non-update answer message, sends 
it to the third process unit CP of the inquiring user Uj; 

(g) if the object software of the same version type as the 
current version of user Uj has been updated, then module 
delete/add instruction information and information about 
modules to be added are generated as an update instruction 
message as an answer, and the generated answer is sent to 
the third process unit CP of the inquiring user Uj over the 
network 12; and 

(h) if it is determined that the current version should be 
switched to a newly served version of object software Si, 
then generates a non-update and information message about 
a newly served version, and sends the generated information 
message to the third process unit CP of the inquiring user Uj 
over the network 12. 

In the user computer 11; 

(i) The third process unit CP is activated when it receives an 
update instruction message or a non-update message from 
vendor Vk over the network 12. 

(j) The third process unit CP obtains the name of a desti- 
nation user and the name of an object software from the 
header of the received message, refers to the corresponding 
user management data UDj, and confirms that the third 
process unit CP is currently in a standby state after inquiry 
and that the sender is a correct vendor Vk; 
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(k) if it receives a non-update message, records the received 
message and the process result, and returns to a standby 

(1) if it receives an update instruction message, invokes a 
5 user-defined update reception process procedure, refers to 
the update instruction information in the received message, 
stores in the user computer 11 the software specified by the 
update instruction message, and actually installs the soft- 
ware if the specified software is acceptable, and 
1Q (m) records the received message and the process result, and 
returns to a standby state. 

If the third process unit CP receives a message from 
vendor Vk, and stores or installs in the user computer 11 new 
software, newly served software, or updated software 
received from vendor Vk, then the third process unit CP 
15 monitors the result of these processes and sends to the fourth 
process unit SP over the network 12 a process result con- 
firmation message informing whether the process has ter- 
minated normally or abnormally. 

Function of the Second Embodiment of the Present Inven- 

20 tion 

Function of the System 

In FIG. 2, if users Ul, U2, . . . activate an purchase inquiry 
instruction by specifying necessary software and vendors 
VI, V2 then the third process unit CP sends an purchase 

25 inquiry message to vendors VI, V2 

The fourth process unit SP of each vendor receives the 
message, checks the user's qualification, automatically per- 
forms processes according to vendor management data 
VDI, VD2, . . . , and answers the user. 

30 The third process unit CP which sent the purchase inquiry 
message receives the answer and sends it to the user. If entire 
software is returned, the third process unit CP stores the 
software according to the instruction information in the 
answer. 

35 The third process unit CP refers to user management data 
UD1, UD2, ... to compile and link programs and automati- 
cally install the software at a predetermined area. 
Furthermore, if users Ul, U2, . . . want to inquire whether 
or not the current software used by the users has been 

40 updated, and, in case of being updated, want to request the 
updated version of software, the users activate the third 
process unit CP with an update inquiry instruction. The third 
process unit CP refers to user management data UD1, UD2, 
... to extract the configuration of software Si.V currently 

45 being used by the user, add user identification information, 
and sends to vendors VI, V2, ... an automatic update 
inquiry message. 

If the fourth process unit SP receives the message, it 
checks the qualification of the user according to vendor 

50 management data VDI, VD2, . . . , and returns software 
update information only to the qualified user. It returns "no 
update" information if the software has not been updated, 
and returns a method of updating the software at user site 
and the software itself required for the update if the software 

55 has been updated. If the third process unit CP receives the 
above described answer from the fourth process unit SP, then 
it first stores the updated software according to the answer 
message and based on user management data UD1, 
UD2, . . . , replaces the old version according to the update 

60 instruction information, etc. in the answer message with the 
newly stored version, and compiles and links programs if 
necessary to set the new version in an executable format. 

The update inquiry can be activated alternatively by a 
user, by an automatic activation caused by the user's invoke 

65 of the object software, and by an automatic activation at a 
time specified by a demon program (for example, every 
dawn, every week, every month, etc.). 
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If the software managed by the third process unit CP 
abnormally terminates in the user computer 11, then the third 
process unit CP detects the cause and the state of the 
abnormal termination, and automatically sends a fault report 
message to vendors VI, V2 

The fourth process unit SP records the message, reports it 
to the software developer, and returns a fault information 
acknowledgement message to the user. 

Bugs are manually corrected by a software developer, and 
the correction is entered in the object software library of the 
vendor. Afterwards, an updated version is immediately pro- 
vided for all the users. 

As described above, the distribution and maintenance of 
object software is managed over the computer network 12 to 
which a number of users Ul, U2, . . . who actually use plural 
sets of object software SI, S2, . . . and a number of software 
vendors VI, V2, . . . who supply the users with the above 
listed object software are connected. The software 
distribution/maintenance system comprises, in each user 
computer 11, object software SU1, SU2, ... to be used by 
users Ul, U2, . . ., and a third process unit CP for managing 
plural sets of object software SU1, SU2, . . . ; and, in each 
software vendor computer 13, vendor software libraries 
SL1, SL2, . . . and a fourth process unit SP for providing 

services relating to the software libraries SL1, SL2 The 

computer network 12 connects each user computer 11 to its 
vendor computer 13. As a result, a number of software 
vendors and users can distribute and use desired software, 
and various software developed and updated by software 
vendors can be distributed to users quickly and appropri- 
ately. 

When any object software abnormally terminates during 
the operation, the third process unit CP detects and analyzes 
the abnormal condition, and then automatically sends the 
fault report to the fourth process unit SP of vendors VI, 
V2, . . . over the network 12. The fourth process unit SP of 
vendors VI, V2, . . . receives the fault report and informs 
vendors VI, V2, ... of the fault. As a result, the software 
vendor immediately detects the occurrence of the fault of the 
software and can take an immediate action against the 
software fault. 

A single computer can be used by users Ul, U2, ... of a 
version of software and at the same time by vendors VI, 
V2, . . . , and furthermore, a single computer can be provided 
with one or more third process units CP and one or more 
fourth process units SP. As a result, a computer and also a 
person using a computer can have a simultaneous role of a 
user and a vendor. This also allows, if properly authorized, 
easy re-distribution of software. 

Each user computer 11 can be designed to store user 
management data UD1, UD2, ... for each of users Ul, 
U2, ... or each user group, and the data can be set for each 
object software. The third process unit CP refers to user 
management data UD1, UD2, ... to manage one or more 
sets of object software SU1, SU2, ... As a result, the third 
process unit CP can be unified among users, and various 
settings can easily be defined for respective users and for 
respective software. 

User management data UD1, UD2, ... can be designed 
to comprise user identification information of each user Ul, 
U2, ... or each user group, software management informa- 
tion of each object software used by each user Ul, U2, . . . 
, software configuration information, and message process 
method specification information. As a result, the third 
process unit CP can be unified among users, and various 
settings can be easily defined for respective users and for 
respective software. 
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Users Ul, U2, . . . can specify a process method as a 
procedure for each function performed by the third process 
unit CP. As a result, the third process unit CP can be unified 
among users, and an appropriate process method can be 

5 defined for each user and for each software. 

Among message processing methods in user management 
data UD1, UD2, . . . , a vendor confirmation procedure can 
be specified. As a result, the third process unit CP can be 
unified among users and software, and a method of con- 

10 firming the vendor can be defined for each user and for each 
software. 

When the fourth process unit SP of the vendor computer 
13 offers services using software libraries SL1, SL2 . . . , it 
can refer to vendor management data VD1, VD2 stored for 

15 each software library SL1, SL2, ... As a result, the fourth 
process unit SP can be unified for software libraries Sll, 

SL2 and each vendor can easily and properly define 

various settings for each software library. 

Vendor management data VD1, VD2 can be designed to 

20 comprise the vendor identification information, software 
management information, software configuration 
information, message process method specification 
information, customer information, and fault history infor- 
mation. As a result, the fourth process unit SP can be unified 

25 for software libraries SL1, SL2, . . . , and each vendor can 
easily and properly define various settings for each software 
library. 

When a message process method is specified using vendor 
management, data VD1, VD2, vendors VI, V2, . . . can 

30 specify a method of the process as a procedure for each 
function performed by the fourth process unit SP. As a result, 
the fourth process unit SP can be unified for vendors, and 
each vendor can easily and properly define various settings 
for each process method and for each software library. 

35 When a message process method is specified using vendor 
management data VD1, VD2, a user confirmation procedure 
can be specified. As a result, the fourth process unit SP can 
be unified for vendors, and each vendor can easily and 
properly define various settings of a user confirmation 

40 process method for each software library. 

Users Ul, U2, . . . can simultaneously obtain and use a 
plurality of versions of each object software. As a result, a 
user can use the software of an old version which can be 
easily manipulated with good stability as well as the soft- 

45 ware of a new version having new functions, thereby 
improving the utility of the software. 
Function of the Processing Method 

The distribution and maintenance of object software is 
managed over the communications network 12 to which a 

50 number of users Ul, U2, . . . who actually use plural sets of 
object software SI, S2, . . . to be distributed, managed, and 
maintained and a number of software vendors VI, V2, . . . 
who supply the users with the above listed object software 
are connected. The software distribution/maintenance sys- 

55 tern comprises, in each user computer 11, object software 
SU1, SU2, ... to be used by users Ul, U2, . . . , and a third 
process unit CP for managing plural sets of object software 
SU1, SU2, . . . ; in each software vendor computer 13, 
vendor software libraries SL1, SL2, and a fourth process 

60 unit SP for providing services related to the software librar- 
ies SL1, SL2, . . . ; and a network 12 for connecting each user 
computer 11 and vendor computer 13. This system performs 
processes (a) through (e). Thus, a number of software 
vendors and users can distribute, maintain and use desired 

65 software, and various software developed and updated by 
software vendors can be distributed to and maintained at 
users quickly and appropriately. 
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When any object software managed by the third process 
unit CP in the user computer 11 abnormally terminates 
during its operation, the third process unit CP detects and 
analyzes the abnormal condition, and then sends the fault 
report message to the vendor Vk of the software over the 
network 12. The fourth process unit SP of vendor Vk 
receives the fault report message over the network 12, and 
informs the vendor Vk of the fault. As a result, the software 
vendor immediately detects the occurrence of the fault of the 
software and can take an immediate action against the 
software fault. 

Function of Management Data and Processing in a User 
Computer 

Each user computer 11 can be designed to store user 
management data UD1, UD2, ... for each of users Ul, 
U2, ... or each user group, and the data can be set for each 
object software. The third process unit CP refers to user 
management data UD1, UD2, ... to manage one or more 

sets of object software SU1, SU2, As a result, the third 

process unit CP can be unified among users, and various 
settings can easily and properly be defined for respective 
users. 

User management data UD1, UD2, ... can be designed 
to comprise at least user identification information of users 
Ul, U2, ... or each user group, software management 
information of each object software used by the user, soft- 
ware configuration information, and message process 
method specification information. The third process unit CP 
refers to user management data UD1, UD2, ... As a result, 
the third process unit CP can be unified among users, and 
various settings can easily and properly be defined for 
respective users. 

In referring to a method of processing a message accord- 
ing to user management data UD1, UD2, . . . , users Ul, 
U2, . . . can specify and use a process method as a procedure 
for each function performed by the third process unit CP. As 
a result, the third process unit CP can be unified among 
users, and an appropriate process method can easily and 
properly be defined for each user. 

In referring to the message processing methods in user 
management data UD1, UD2, . . . , a user defined vendor 
confirmation procedure can be used so that the message 
received by the third process unit CP can be recognized as 
a correct message from the predetermined vender Vk. As a 
result, the third process unit CP can be unified among users, 
and a method of confirming the vendor can easily and 
properly be defined for each user and for each software. 

When users Ul, U2, . . . activate the third process unit CP 
in the user computer 11 by inputting a command, the third 
process unit CP obtains a user name, a command name, and 
an object software name to generate an interactive screen 
displaying messages according to the input command, pro- 
motes the generation of a message in response to the 
command from user Uj by referring to user management 
data UDj of user Uj and object software Si or by invoking 
a user-defined process procedure, sends the generated mes- 
sage to the fourth process unit SP of the computer of vendors 
Vk of object software Si, and returns to a standby state after 
recording the transmission of the message. As a result, users 
can easily generate a message in an interactive mode, 
thereby allowing unskilled users to easily utilize software. 

If the third process unit CP is activated in the user 
computer 11 by an input command from a user program or 
through an abnormal termination of the object software 
managed by the third process unit CP, the third process unit 
CP obtains a user name, a command name, and an object 
software name, promotes the generation of a response mes- 
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sage by referring to user management data UDj and object 
software Si or by invoking a user-defined process procedure, 
sends the generated message to the fourth process unit SP of 
the computer of the vendor Vk of object software Si, and 

5 returns to a standby state after recording the transmission of 
the message. As a result, the third process unit CP can be 
activated when a user activates object software, when the 
object software abnormally terminates, or when a demon 
program sends a command, etc. If an update inquiry is issued 

10 whenever the object software is activated, the user can 
always use an updated object software. If update inquiries of 
object software are made through the demon program, at 
night, in an early morning, etc., then the inquiries can be 
answered without a wait at, for example, the activation of the 

15 object software. Furthermore, activating the third process 
unit CP at, for example, an abnormal termination allows the 
software vendor to immediately detect bugs of the supplied 
software, thereby performing a quick maintenance process. 
If the third process unit CP is activated in the user 

20 computer 11 by a message received from the network 12, 
then the third process unit CP obtains from the header of the 
received message a destination user name, a command 
name, and an object software name, uses user management 
data UDj for the specified user Uj and object software Si, 

25 then obtains a sender name from the header of the received 
message, confirms that the sender is a right vendor Vk of 
object software Si, also confirms that the third process unit 
CP is in an answer-wait state, refers to user management 
data UDj or invokes the user-defined process procedure 

30 depending on the command in the received message, ana- 
lyzes or stores the message data or stores or installs the 
software specified by the message, returns, in response to a 
specific message which requires acknowledgement, the 
acknowledgement to the fourth process unit SP over the 

35 network 12, and then returns to a standby state after record- 
ing the transmission of the message. As a result, when the 
third process unit CP receives a message, it confirms the 
vendor, analyzes the message, installs the software accord- 
ing to the message based on user management data UD1, 

40 UD2, . . . and a user-defined process procedure. 

The third process unit CP performs the processes depend- 
ing on the cause of the activation of the third process unit CP. 
As a result, the third process unit CP can be activated at an 
appropriate timing. 

45 Each time the third process unit CP is activated, a new 
process is generated.to allow plural processes to be per- 
formed in parallel on the processes other than the process 
relating to a specific object software of a specific user. As a 
result, a plurality of processes such as purchase requests, 

50 update inquiries, etc. from a plurality of users can be 
concurrently performed. 

Function of Management Data and Processing in a Vendor 
Computer 

When the fourth process unit; SP in the vendor computer 

55 13 offers services using software libraries SL1, SL2, . . . , 
vendor management data VDi, which is stored for each 
software library SLi, is referrence. As a result, the fourth 
process unit SP can be unified for software libraries SLI, 
SL2, . . . , and vendors can easily and properly define various 

60 settings for each software library. 

When the fourth process unit SP refers to vendor man- 

■ agement data VDi for a software library SLi, it refers to at 
least the vendor identification information, software man- 
agement information, software configuration information, 

65 message process method specification information, cus- 
tomer information, update history information, and fault 
history information. As a result, the fourth process unit SP 
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can be unified for software libraries SL1, SL2, . . . and 
vendors can easily and properly define various settings for 
each software library. 

When a message process method in the vendor manage- 
ment data VDi is referred to, vendor Vk can invoke the 
process method as a procedure for each function performed 
by the fourth process unit SP. As a result, the fourth process 
unit SP can be unified among vendors, and each vendor can 
easily and properly define various settings for a process 
method. 

When a message process method in the vendor manage- 
ment data VDi is referred to, a user confirmation procedure 
can be invoked to confirm the identity of user Uj who is a 
sender of the message, determine the qualification of the 
user, and return appropriate answer to the user. As a result, 
a method of confirming and qualifying a user can be defined 
for each vendor, and the present invention can De used in 
distributing various types of software. 

In the user confirmation procedure as a part of the vendor 
management data VDi, the qualification of a user can be 
determined on the basis of commercial relations such as 
contracts relating to the object software, payments relating 
to the object software, payments relating to new services for 
the object software, etc. As a result, the present invention 
can be used in distributing various types of software, includ- 
ing commercial product software. 

In the user confirmation procedure as a part of the vendor 
management data VDi, the object software can be provided 
and distributed only to specified users Ul, U2, ... by 
referring to their identification information such as the 
organizations to which they belong, their titles, personal 
names, etc. As a result, the present invention can be used in 
distributing various types of software, including contract- 
base software and intra-office software. 

In the user confirmation procedure as a part of vendor 
management data VDi, users Ul, U2, . . . can be identified 
by passwords. As a result, software can be protected from 
being distributed to an unqualified user. This makes the 
present invention applicable to distribute various types of 
software, including product software and intra-of fice soft- 
ware. 

The user computer 11 and the vendor computer 13 need 
to be connected to the network 12 only when it sends or 
receives messages to or from each other. As a result, even a 
computer not constantly connected to the network can 
supply/obtain desired software, in a way similar to the 
communication by mails and telephones. This feature makes 
the present way of software distribution to be cost-effective 
and widely applicable. 

The header of a message transmitted over the network 12 
specifies the destination and the source of the message. 
Additionally, the title column of the message specifies the 
name of a software distribution/maintenance system, the 
name of a software distribution/maintenance process type, 
and the name of the object system. As a result, the 
destination, sender, system name, etc. can be easily informed 
of. 

The fourth process unit SP in the vendor computer 13 
performs the processes (a)-(g). As a result, when the fourth 
process unit SP receives a message, it determines the access 
qualification of a user, analyzes the message, and generates 
an answer message according to the received message. 

Each time the fourth process unit SP is activated, a new 
process is generated to allow a plurality of processes to be 
concurrently performed on the processes other than the 
process relating to the same object software and the same 
user. As a result, a plurality of processes can be concurrently 
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performed on the messages received from a number of users 
over a network. 

Function of Distribution and Maintenance Processes 
When users Ul, U2, . . . obtain the summary information 

5 of the object software not yet used by them, the processes 
(a)-(f) are performed. As a result, summary information 
required by qualified users Ul, U2, . . . can be provided 
quickly and appropriately. 

When users Ul, U2, . . . newly obtain an object software 

1Q not yet used by them, the processes (a) — (j) are performed. 
As a result, a newly served object software required by 
qualified users Ul, U2, . . . can be provided quickly and 
appropriately. Since the new version can also be installed, an 
unskilled user can easily utilize an obtained object software. 
When users Ul, U2, . . . add or switch to a new service 

15 of an object software already used by them, the processes 
(a)-(j) are performed. As a result, a newly served object 
software required by qualified users Ul, U2, . . . can be 
provided quickly and appropriately. Since the new service of 
the supplied software can also be installed, an unskilled user 

20 can easily utilize an obtained object software. 

When users Ul, U2, . . . inquire the update state of an 
object software already used by them of vendors VI, V2, . . . 
and request to send an updated software, the processes 
(a)-(m) are performed after entering a new service request 

25 command and activating the third process unit CP in the user 
computer 11. As a result, qualified users Ul, U2, . . . can be, 
at any time, quickly informed of whether or not update 
information exists. If the object software has been updated, 
then the updated object software can be obtained immedi- 

30 ately. Furthermore, since the updated software can also be 
installed, an unskilled user can readily utilize the object 
software obtained. 

When the third process unit CP is activated by update 
inquiry command issued from the user's program, processes 

35 (a)-(m) are performed. As a result, qualified users Ul, 
U2, . . . can automatically update object software at night or 
in an early morning, for example, if update information 
exists. Thus, a user can constantly utilize updated object 
software. Furthermore, since the updated software can also 

40 be installed, an unskilled user can readily utilize the object 
software obtained. 

If the third process unit CP receives a message from 
vendors VI, V2, . . . and stores or installs in the user 
computer 11 new software, newly served software, or 

45 updated software received from vendor Vk, then the third 
process unit CP monitors the result of these processes and 
sends to the fourth process unit SP of vendors VI, V2, . . . 
over the network 12 a process result confirmation message 
informing whether the process has terminated normally or 

50 abnormally. As a result, the vendor can recognize a process 
result in the user computer 11. 
Explanation of the Preferred Embodiments 
Explanation of the First Preferred Embodiment 
(1) System Configuration 

55 FIG. 3 shows the configuration of the system according to 
the first embodiment. In FIG. 3, computers 21-1 and 21-2 
respectively belong to users A and B. Each of the computers 
21-1 and 21-2 is equipped with a client program CP for 
automatically updating the software in the user computer 

60 and sending fault information. 

The computer of user A stores; software Si of an old 
configuration, and the computer of user B stores the same 
software Si of the latest version. The software is managed by 
the client program CP. As described above, software is 

65 identified as Si.V.l in the full notation, but in the first 
embodiment, the software of a certain type can simply be 
represented as Si.l. 
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A computer 22 belongs to a vendor and comprises a server 
program SP used to automatically update software in a user 
computer; and a software library SL (of one type) managed 
by the server program SP. 

A communications network 23 connects the user comput- 5 
ers 21-1 and 21-2 to the vendor computer 22, and the client 
program CP and the server program SP exchange informa- 
tion over the network 23. The network 23 can be either a 
private line or a common line, establishes connections 
through the client program CP or the server program SP, and 10 
only has to be used during the transmission of the informa- 

The server program SP in the vendor computer 22 man- 
ages (specifically manages the version number and the 
configuration of software) the object software library SL 15 
which is obtained through development/maintenance pro- 
cesses performed by a vendor. If the server program SP 
receives from the client program CP in the user computers 
21-1 and 21-2 the information of a user's current software 
configuration, then it compares the information with the 20 
corresponding software library SL, and automatically 
returns to the client program CP the update instruction 
information for updating user software SI and S2 together 
with updated software modules. 

The software library SL in the vendor computer 22 25 
comprises a plurality of modules Ma, . . . , Mn, stores 
information about bug correction, update, added functions, 
added modules, etc. of each module, and maintains the 
version numbers and configurations of each module. For the 
sake of simplicity of explanation, simple representation is 30 
assigned to a module using symbols and numbers. 

In the software library SL shown in FIG. 3, while the 
conventional version comprises the modules Ma, . . . , 
Mi, . . . , Mm, module Mi is updated into Mi* and new 
module Mn is added. Thus, the latest version comprises 35 
modules Ma, . . . , Mi*, . . . , Mm, Mn. 

The client program CP in the user computers 21-1 and 
21-2 manages the configuration of the object software. If an 
object software is activated, the client program CP extracts 
the information of the configuration of the current software 40 
(current version information) before the execution of the 
software, sends the information to the server program SP 
through the network 23, and inquires whether or not the 
information refers to the latest version. 

Upon receipt of an answer from the server program SP, 45 
the client program CP updates the object software in the user 
computer if necessary according to the instruction in the 
answer. Then, it activates the updated software according to 
the user-activated instruction. 

In FIG. 3, the software Si in the computer 21-1 of user A 50 
comprises modules Ma, . . . , Mi, . . . , Mm of the old 
configuration, while the one in the computer 21-2 of user B 
comprises modules Ma, . . . , Mi*, . . . Mm, Mn of the latest 
configuration. These modules are managed by the client 
program CP. 

In FIG. 3, when user A tries to activate software Si in the 
user computer 21-1, the client program CP detects it and 
inquires the server program SP in the vendor computer 22 
over the network 23 by sending the information about the 
current version. According to the example shown in FIG. 3, 
software Si of the user computer 21-1 comprises modules 

Ma, . . . , Mi Mm, and the configuration information 

is sent to the server program SP over the network 23 for 
inquiry. 

Upon receipt of the information, the server program SP 
compares the information with the configuration of the 
software library SL, and returns the instruction information 
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for updating software Si of user A together with the updated 
software. In this example, returned is the instruction inform- 
ing that module Mi is updated into Mi* and module Mn is 
added and the body of the updated module Mi* and added 
module Mn. 

The client program CP of user A automatically updates 
software Si into the latest version using the information. 
According to the example, software Si in the user computer 
21-1 is updated into modules Ma, . . . , Mi*, . . . , Mm, Mn. 
As a result, software Si of user A is updated to the latest 
version, just like the software Si of the computer of user B. 
Then, the client program CP activates the latest software 
according to the instruction of user A. 
(2) Automatic Update of User Software 

Described below is the automatic update process per- 
formed when a user activates the object software in the user 
computer. 

(i) Process in User Computer 

FIG. 4 is a flowchart showing the process in which a 
program stored in a user computer is automatically managed 
and updated in the system shown in FIG. 3. The process of 
a client program is described below by referring to FIG. 4. 

If a user activates the object software in step SI, the client 
program CP managing the object software is automatically 
activated in step S2. 

In step S3, the client program CP extracts the version 
information of the current object software. For example, in 
the case of user A shown in FIG. 3, the configuration 
information of modules Ma, . . . , Mi, . . . , Mm is extracted. 
Then, in step S4, the client program CP sends the current 
version information to the server program SP over the 
network 23. 

In step S5, the client program CP receives from the server 
program SP the update instruction information of the object 
software and the updated software. 

If the software has not been updated, then the update 
instruction information informs of no need of update. If the 
information tells no need of update or deletion of modules 
only, then no updated software is transmitted. If the software 
should be updated, then updated software is received, but 
received is only the modules to be updated into. 

In the example of user A shown in FIG. 3, the instruction 
to delete Mi and add Mi* and insert Mn is received as the 
update instruction information as described above. The 
software of module Mi* and Mn are received as updated 
software. 

In step S6, necessary processes are performed according 
to the update information. That is, if update instruction 
information indicates the update of modules, then specified 
modules are deleted from the object software and updated 
modules are added to the original modules. If the update 
instruction information tells no need of update, then no 
actions are taken. 

Thus, the object software in the user computer matches 
the software library SL of the vendor. 

In the example shown in FIG. 3, the object software in the 

computer of user A is updated into modules Ma 

Mi*, . . . , Mm, Mn as described above. If the object software 
in the user computer is updated as described above, it is 
compiled and linked before the execution, if necessary, in 
step S7. In step S8, the client program CP is suspended after 
terminating its process. 

In step S9, the object software is activated to start its 
execution according to a user's activation instruction. At this 
time, according to the above described steps S2-S8, it is 
guaranteed that the object software is the latest version of the 
software provided by the vendor. 
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(ii) Process Performed by Vendor Computers 

FIG. 5 shows the process performed by a vendor com- 
puter. The process performed by the server program SP in 
the vendor computer 22 is described below. 

In step Sll, the server program is activated in the vendor 
computer 22 and set in a standby state. 

In step S12, the server program receives an update inquiry 
from a client program in any user computer over the network 
23, and receives the configuration information of the object 
software's current version. In the example shown in FIG. 3, 
the information received in an inquiry from user A indicates 
the module configuration of Ma Mi Mm. 

In step S13, the server program SP compares the con- 
figuration with that of the object software in the software 
library SL managed by the server program SP, and generates 
update instruction information used to update the object 
software of the inquiring user. If the configuration of the 
user's current version matches the configuration in the 
software library SL, then the update instruction information 
tells "no need of update". 

In the example of user A shown in FIG. 3, the update 
instruction information tells "delete Mi and add Mi* and 
Mn". 

In step S14, the server program SP answers the inquiring 
client program CP with the update instruction information 
and the updated software required to update the user soft- 
ware. 

As described above, the entire updated software is not 
sent, but only the updated or added modules are sent to the 
client program. In the example of user Ain FIG. 3, the above 
described update instruction information and the software 
modules Mi* and Mn are returned. 

In step S15, the server program SP is returned to a standby 
state, and control is returned to step S12 upon receipt of an 
inquiry. These processes are repeatedly performed. 

(3) Periodical Automatic Update and User-Defined Update 
of User Object Software 

Some users do not like to be kept waiting in updating the 
software to be processed according to the above embodi- 
ment of the activation of update inquiry at the time of user's 
activation of the object software. 

In such cases, the object software can be automatically 
inquired for update and then automatically updated. 

To attain this, a demon program can activate for the user 
the client program CP in the above described embodiment. 

FIG. 6 shows the activation of the client program through 
the above described demon program. FIG. 6 differs in steps 
SI and S9 from the processes shown in FIG. 4, and remains 
the same in steps S2 through S8. 

In FIG. 6, if the demon program is activated at predeter- 
mined intervals, e.g. at night, it executes an instruction to 
activate the client program on the object software in step 
S21. Then the client program is activated in step S2, and the 
above described processes are performed in steps S2-S8. 

If the client program is suspended in step S8, the demon 
program terminates in step S22. 

Instead of activating a client program with a demon 
program, a user can directly enter a command, to activate the 
client program. Thus, the object software can be automati- 
cally activated whenever necessary. 

(4) Automatic Transmission of Software Fault Information 
The client program CP shown in the present embodiment 

automatically transmits to the vendor computer 22 the object 
software fault/bug information detected in the user comput- 
ers 21-1 and 21-2 so that the information is transmitted to the 
developer of the software. 

That is, while the object software is executed in the user 
computers 21-1 and 21-2, the object software may work in 
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an unexpected manner and terminate abnormally. This is 
caused by a fault/bug in the object software or in the 
software used by the object software. 

In this case^ the client program CP collects the informa- 
5 tion of conditions of the abnormal termination, such as an 
instruction which directly caused the abnormal termination, 
the state of the abnormal termination, a sequence of higher- 
level instructions which invoked the instruction, etc. 
The above described information is immediately trans- 
it) mitted to the server program in the vendor computer 22 or 
the mail box of the developer of the software through the 
network 23. 

The fault/bug information is received by the server pro- 
gram SP in the vendor computer 22, and the developer or the 
15 maintainer of the object software refers to the information 
for correcting the software or for developing a new feature 
of the software. 

If a developer of the software enters a correction in a 
module in the software library SL stored in the vendor 
20 computer 22, then the object software in the user computers 
21-1 and 21-2 can be automatically updated when the client 
program CP issues an update inquiry of the object software. 

The fault/bug information can be transmitted through an 
electronic mail over the network 23. 
25 The user computer 21-2 of user 13 according to the 
embodiment shown in FIG. 3 indicates the state of auto- 
matically sending the fault information. The automatically 
transmitted fault information received by the server program 
in the vendor computer 22, and the fault is reported to the 
30 developer of the software. 
(5) Other Functions 

The following configuration can be designed in the sys- 
tem according to the first embodiment. 

(i) Network Connection 

35 In the above mentioned embodiment, it is essential that a 
user computer and a vendor computer are connected to each 
other over a network. However, the connection is not 
required continuously. That is, a user computer only has to 
be connected by a client program and a server program (or 

40 transmission mail-box programs in the network which relay 
an inquiry from the client program or an answer from the 
server program) over a network from time to time just to 
transmit the messages in steps S4 and S5 shown in FIG. 4. 

(ii) Initial Installation 

45 If a user wants to purchase and install software provided 
with the above mentioned automatic update function, the 
software should be obtained and installed in any of the above 
listed methods (a), (b), and (c) of the prior art technologies. 
If a network is available, the easiest method is to obtain 

50 and install a client program for software to be obtained 
through method (c), for example. 

Activating the update inquiry of software to be obtained 
as if the object software were stored already in the user 
computer allows the client program to issue an inquiry to the 

55 vendor computer and to receive the entire module of the 
latest version from the vendor computer over the network. 
The received module can be installed and executed in the 
user computer. 

(iii) Distribution of Non-execution Information and Auto- 
60 matic Update' 

The software to be processed according to the present 
embodiment can be information of the software such as 
explanation of new services, user handbooks, examples, etc. 
as well as an executable program. The information can be 
65 processed as if it were a module. 

Thus, the information of the latest version can be always 
provided for a user by a vendor. 
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(6) Practical Embodiment of the Present Invention 

The system shown in FIG. 7 is designed using a UNIX 
network connecting a computer to work stations based on 
the client/server system in an X window system which is a 
typical multiwindow system. 

The system configuration and the processes performed by 
the client program and the server program are the same as 
those shown in FIG. 3. 

As for a software library SL in a vendor computer 27, a 
directory in the UNIX file system is used as a library of the 
modules of the object software. Each module is used as a 
UNIX source file, and a file name is a unique module 
identification name followed by a version number as an 



That is, in FIG. 7, Ma.l and Mi.2 are generated by adding 
the numbers 0.1 and 0.2 to the end of the module identifi- 15 
cation names Ma and Mi respectively. The software in user 
computers 26-1 and 26-2 is entered in a UNIX directory. 

The client program CP is stored in the user computers 
26-1 and 26-2 and manages the extraction of library 
information, update of the software, and communications to 20 
the server program SP over a network 28. 

When a user activates the object software, the client 
program CP generates a list of file names in a directory 
managed by the client program CP, and transmits it to the 
server program SP of the vendor computer 27. The client 25 
program CP receives an answer from the server program SP 
of the vendor computer 27, and deletes unnecessary files and 
enters received files (or modules) according to an instruction 
of the server program SP. 
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The fault information is transmitted to the server program 
SP over a network. In this example, the information is 
transmitted by electronic mail. In the example shown in FIG. 
7, the user computer 26-2 of user B automatically transmits 
5 the fault information to the vendor computer 27. 

In the present embodiment, the object software actually 
generated and operated is multifunction and multimedia 
information retrieval software which is similar to a hyper 
text, and is described in tcl/tk language, that is, a kind of 
10 script language. 

An example of fault/bug information automatically trans- 
mitted by an electronic mail from a client program of a user 
computer is shown. 
Date; Thu. 28 Oct 93 16:36:12 JST 
15 From; userA@ling.flab.fujitsu.co.jp(User NameA) 
To; yuji@iias.flab.fujitsu.co.jp(Yuji takada) 
Subject; ISISinfo bug! 



couldn't find "/bin/play" to execute while executing 
"exec /bin/play - V 20 yujil0488/yuji.au"("eval" body line 

1) invoked from within 
"eval exec /bin/play - V 20 yujil0488/yuji.au"invoked from 

within 

".bw View.bwl048.media.voice invoke" 
. . . "tk-butUp.bwView.bwl0488.media.voice"(command 
bound to event) 

Data 1 describe the date, sender, destination, and o 



The vendor computer 27 stores the server program SP 30 rence of abnormal termination; data 2 describe the instruc- 



which manages a library of the object software and the 
versions of all modules based on the development and 
update of the software developer. 

When module configuration information of the user com- 
puter is transmitted from the client program CP, the server 
program SP receives the information and determines which 
module is required, unnecessary, or an old version in the 
software configuration of the client. Then, the server pro- 
gram SP specifies the names of the modules to be deleted 
and installed to generate update information as an answer to 40 
the client program CP. The update information and the 
modules to be installed are provided for the client program 
over the network 28. 

The example in FIG. 7 shows that modules Ma.l, Mil, 
and Mm.l are transmitted as the object software of the 45 
current version from the user computer 26-1. 

The server program SP in the vendor computer 27 
receives the information, compares the received current 
version information with the files in the object software 



tion which caused the abnormal termination, and the cause 
of the abnormal termination (in this example, the message 
tells that "/bin/play/" cannot be found); and data 3 describe 
higher-level instruction sequence which invoked the instruc- 
35 tion that caused the abnormal termination. 

According to the first embodiment, the functions and 
descriptive language of the software is not limited to the 
above described example, but can be optionally selected in 
the range of the first embodiment. 
40 Effects of the First Embodiment 

According to the first embodiment, as described above, a 
user computer stores a client program for managing the 
configuration and the execution of the object software, and 
a vendor computer, which is connected to the user computer 
over a network, stores a software library and a server 
program for managing a software library and automatically 
updates and remotely manages the software of the user 
computer. Therefore, problems (1)-(10) of the prior art can 
be successfully solved. The effects of the first embodiments 



library SL to determine which module is required, 50 can be listed corresponding to the respective problen 



unnecessary, or an old version. Then, the server program SP 
of the vendor computer 27 generates "delete Mi.l, add Mi.2 
and Mn.l" as update instruction information, and sends the 
update instruction information and the updated software 



Mi.2 and Mn.l for update to the user computer 26-1. When 55 of u: 



follows. 

The effects from the viewpoint of a vendor are that: 
(1) A vendor can automatically recognize the current 
configurations of the software in the computers of a number 



the user computer 26-1 of user A receives the information, 
the client program CP updates the object software based on 
the received information. 

In the example, the client program CP is provided with the 
function of automatically analyzing and transmitting the ( 
fault/bug information described in (4) above. 

That is, if the object software in the user computers 26-1 
and 26-2 abnormally terminates during the execution, it 
locates the direct cause of the abnormal termination and the 
source of the related instruction, and lists the instruction < 
sequence associated with the related instruction. The infor- 
mation is described as fault/bug information. 



This facility forms the basis of software maintenance 
services and allows the software maintenance services to be 
realized efficiently and smoothly. 

(2) If the vendor detects a bug and corrects the software 
library of the vendor, then the user who executes the object 
software in the user computer can automatically execute the 
updated software, thereby allowing the user to be immedi- 
ately given the bug correction service from the vendor. 

(3) If the vendor enters new services such as extended 
functions, new versions, etc. in the software library, then 
they can be immediately provided for a number of users who 
actually use the software. 
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(4) The vendor can automatically recognize who the users 
actually use the software are, and automatically provide 
them the latest software and the latest related information. 

(5) Since the system of the present invention can auto- 
matically install (re-install) the software in the user 
computers, the vendor does not have to visit the users to 
install the software, but makes all services available to the 
users. 

On the other hand, the effects from the viewpoint of a user 
are that: 

(6) The system according to the present invention auto- 
matically installs the software and manages updated ver- 
sions of the software. Therefore, the user are not required of 
special skills and efforts. Even a beginner or an unskilled 
user can be sufficiently provided with the latest services of 
the software. 

(7) When the software in the user computer becomes 
faulty, the management system automatically reports the 
exact information of the fault to the vendor. In response to 
the report, the vendor removes the fault and corrects the 
software library. Then, the user can immediately use and 
execute the corrected software. 

Since all the above listed processes are performed auto- 
matically except the correction process by the vendor, users 
are not loaded with additional work. 

(8) If the vendor enters newly added functions and 
versions in the software library, they are automatically 
available to the users in the user computers when the users 
first use the software immediately after the entry. Thus, the 
users are free of extra time or jobs. 

(9) The uses are not required to know the information of 
correcting bugs, adding functions, starting a new version, 
etc. When these services are issued, they are automatically 
available to the users, thereby preventing the users from 
being kept using the software as an old inconvenient version. 

(10) The users are free of frequent information from the 
vendor or a troublesome installation process pertaining to 
the correction of bugs and addition of functions. The users 
can automatically access all new services. 

Summing up the above listed effects of the present 
invention, the users can be automatically provided with new 
services of a new version of the software which replaces its 
old version in the user computer immediately after the 
vendor enters in the vender computer the correction of bugs, 
addition of functions, and generation of new versions for the 
software. 

Additionally, considering that a large number of users (as 
many as thousands or even millions of users) use the 
software at various locations in the world, the effects of 
automatic distribution and update of the software using the 
software distribution/maintenance system over a network 
can be greatly evaluated by the vendors and users. 

Explanation of the Second Preferred Embodiment 
Described below in detail is the second embodiment of 
the present invention. 
(1) System Configuration 

FIG. 8 shows the system configuration according to the 
embodiment of the present invention. In FIG. 8, 31, 32, and 
33 are user computers. 

In FIG. 8, the user computer 31 stores SI. V, S2.V; the user 
computer 32 stores software S2.V for user U2 and software 
Sl.v", S3.V for user U3; and the user computers 33 stores 
software Sl.V, S3.V". The user computer 31 is used by user 
Ul; the user computer 32 is used by users U2 and U3; and 
the user computer 33 is used by user U4. The software is 
managed by the system according to the present invention. 
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The software managed by the present system is referred to 
as object software Si, and i identifies the type of object 
software 

A communications network 35 connects the client pro- 
5 grams of the user computers 31, 32, and 33 to the server 
programs of vendor computers 36 and 37. 

Two vendor computers 36 and 37 are shown in FIG. 8, 
and the vendor computers 36 and 37 of vendors VI and V2 
are used to provide the object software of the user computers 
10 31, 32, and 33, and to update the object software. 

FIG. 8 shows a user computer and a vendor computer 
separately. However, a computer can be a user computer and 
a vendor computer simultaneously. 

For example, computer A provides a specific object soft- 
15 ware for another computer B, and updates and maintains the 
object software. Additionally, computer A can use the object 
software provided by same other computer C. FIG. 9 shows 
a computer 38 as an example of the above described 
computer. 

20 In FIG. 8, the software distribution/maintenance system 
according to the second embodiment comprises the follow- 
ing components. 

(i) Server Program SP 

The server program SP is stored in the vendor computers 
25 36 and 37 to provide necessary information and software 
required by user Uj at his or her inquiries and requests. 

According to the present embodiment, the same server 
programs SP is stored in the vendor computers 36 and 37. 
The server program SP generates a new process each time 
30 it is activated, and a plurality of server program processes 
can be performed in parallel unless the processes relate to 
the same object software of the same user. Therefore, the 
server program SP can simultaneously process messages for 
users unless the messages relate to the same object software 
35 of the same user. 

(ii) Vendor Management Data VD (Si) 

The vendor management data VD refer to data including 
vendor identification information, software configuration 
information, customer management information, etc. to be 

40 stored in each software library managed by the server 
program, and data including information (for example, 
procedures) to be used by the server program SP to regulate 
an answering method in an answering process. 
Thus, vendor management data are provided for each 

45 software library, and the server program SP uses the vendor 
management data to set a software-library-dependent pro- 
cess as a procedure, thereby allowing the server program SP 
to be unified. 

According to the second embodiment, the follow ing 
50 information is stored in each object software Si in the vendor 
computers 36 and 37 of each vendor Vk (VI and V2 in the 
embodiment). 

Vendor Identification Information: vendor name Vk, ven- 
dor network address, etc. 
55 Software Management Information: software name Si, 
location of software library SL (Si), version type and 

Software Configuration Information: module configura- 
6Q tion for each version, etc. 

Processing Method Information: user check method, pass- 
word instruction method, version classification method 
using user management information, configuration 
method of install instruction information 
65 Customer Information: user identification information, 
password, contract state, supplied software version, 
supplied history of each customer user Uj, etc. 
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Update History Information: development process history 

information, fault report information, etc. 
Fault Information: fault information history, classified 

fault information, fault correction history, etc. 

(iii) Vendor Software Library SL (Si) 5 
A software library is managed by a vendor and stores each 

software Si comprising various versions Si.V. 

As described above, Si indicates the type of software in 
each object software in a software library. For example, Si 
is a different software from S2. Si.V, Si.V, and Si.V" 1Q 
represent the version types of the same software. For 
example, Si.V is developed for UNIX; Si.V for DOS-V; and 
Si.V" for MSDOS, etc. 

Although not shown in FIG. 8, each of the object software 
Si.V, Si.V, and Si.V" is assigned a version number (for 
example, Si.V.l) indicating update information. The version 15 
number is incremented each time the software is updated, for 
example, Si.V.l, Si.V.2, 

The object software Si.V comprises a number of modules 
Mm.l and the module configuration of each version is set as 
the software configuration information in the vendor man- 20 
agement data VD (Si). Each time a module is updated, the 
version number of module Mm.l is incremented. 

For example, as shown in FIG. 8, object software SI.V 
comprises module Ma.l, Mi.l, Mm.l, and Mi.2, and module 
Mi.2 indicates the updated version of module Mi.l. 25 

The above described vendor management data VD (Si) is 
provided for each software type (for example, for each of 
software SI, S2, . . .) as shown in FIG. 8, and the server 
program SP refers to the vendor management data VD (Si) 
for each type of software to read necessary information and 30 
perform an answering process. 

(iv) Client Program CP 

The client program CP is stored in each user computer to 
send various messages from a user to a vendor, for example, 
a software purchase request, an update inquiry, a fault report, 35 
etc., receive an answer from the vendor, and update user 
software, etc. 

The second embodiment shows an example of the same 
client program CP provided for each of the user Ocomputers 
31, 32, and 33. 40 

The client program CP as well as the server program SP 
generates a new process each time it is activated, and a 
plurality of client program processes can be performed in 
parallel unless the processes relate to the same object 
software of the same user. Therefore, the client program CP 45 
can simultaneously process requests and inquires for users 
unless the messages relate to the same object software of the 

(v) User Management Data UD (Uj) 

The user management data UD are provided for each of 50 
users Ul, U2, U3, and U4 managed by the client program 
CP, and contain user identification information, software 
management/configuration information, and information 
(procedure) regulating an installation method, etc. The user 
management data UD (Uj) is used to update user software 55 
when the client program CP sends various messages such as 
a software purchase request, update inquiry, fault report, etc. 
Thus, as in the case of the server program, the user man- 
agement data provided for each user allow the client pro- 
gram CP to be unified. 60 

According to the second embodiment, the following 
information is set for each user Uj. 

User Identification Information: user name Uj, user net- 
work address, password, computer model, present OS, 
user category, etc. 65 

Software Listing Information: list of software version 
names (Si.V). 
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The following information is provided for each version of 
software. 

Software Management Information: software name Si, 
vendor identification information, version 
specification, software version name Si.V, contract 
state, etc. 

Software Configuration Information: version module con- 
figuration information, etc. 

Process Method Information: sending method, receiving 
method, sender check method, etc. 

Installation process information: procedure of installation 
process, etc. 

(vi) Object Software Si to be Used by Each User 

The object software Si is stored in the user computers 31, 
32, and 33, and each user uses a specific version of each 
software. For example, in FIG. 6, the object software used 
by user Ul is object software SI.V and S2.V. The object 
software used by user U2 is object software S2.V different 
in version type from the above listed object software S2.V. 
Likewise, object software SI.V" and S3.V, and object soft- 
ware SI.V and S3.V" are listed for users U3 and U4 
respectively. 

Typically, each version Si.V may be installed in one 
directory in a user computer, and each module Mm.l may be 
handled as a file. 

A user can own and use a plurality of versions of each 
object software. Thus, the user uses the object software of an 
old version to be used with good stability and the object 
software of a new version having new functions. 

(vii) Network 35 

The network 35 is a common UNIX network and based on 
an electronic mail protocol. For example, it has the message 
configuration. 

To: VendorK@vendor.co.jp 
From: Userj@flab.fujitsu.co.jp 

Subject: SDMP: CheckUpdate Software Distribution Sys- 
tem Message: 
User: (User-Name:Toru Nakagawa) 
Net-Address: User@flab.fujitsu.co.jp), 
Software: (Name: Software Distribution System, 
Version-Type: Standard, 
Current- Version:SOS.S1.2.2. 
Current-Modules: (Ma.l, Mb.3, Mc.2, Md.l, Ref.l)) 

The user computers 31, 32, and 33, and the vendor 
computers 36 and 37 do not always have to be connected to 
the network. That is, either one or both of the user computer 
and the vendor computer have to be connected to the 
network when a message transmitted. 

That is, a message can be transmitted with both the user 
computer and the vendor computer connected to the net- 
work. On the other hand, as in the case of a mail system, a 
user sends a message to a switching station connected to a 
network, and a vendor periodically checks for a message and 
detects the arrival of the message. 

(2) Functions of Software Distribution/Maintenance System 
Described below is each function of the system according 
to the present embodiment, 
(i) Initial Purchase and Installation of Software 

If a user activates an purchase inquiry instruction of the 
client program CP described later by specifying the network 
address of the vendor Vk, then the client program CP sends 
an purchase inquiry message to the software vendor Vk. The 
message is automatically assigned user identification infor- 

The server program SP of the vendor Vk receives the 
message, checks the qualification of the user, automatically 
processes the message according to the settings of the 
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vendor management data VD (Si), and returns it to the user. According to this method, a user can update the object 

The answering process depends on each case. software at any time. 

For example, the server program SP returns only sum- The activation of an update inquiry at the call of the 

mary information, demonstration program, and a payment software by a user is to automatically activate an update 

method, returns the software with an indication clarifying 5 inquiry before the execution of the above described object 

the copyright, or returns the software after confirming the software when the user performs a necessary process using 

user using a public password tne object software. The procedure of an update inquiry 

The client program CP receives the answer and sends it to sendm S V 0 ™** £ a ko set in tbe abov , e . described user 

the user. If the software itself is returned, the client program management data UD (Uj). According to this method, a user 

CP stores the software Si.V according to the update instruc- canconstantly use the software of the latest version. 

„ - f ,. • rpi ° , ,. \ r-n io The system can be designed such that an update inquiry 

tion information m the answer. Then he client program CP can fee a £ tivated when ^ ft terminates abnor- 

refers to user management data UD (Uj) compiles and links mall due tQ a fauU/b etc J Th eyen if a b fe detected 

programs according to the settings in the data and auto- m the object ^ft^f a cor rected object software can be 

matically installs the software at a predetermined area. automatically provided and executed if a corrected and 

(n) Update Inquiry and Update of Software updated version is stored in the software library SL (Si) of 

The client program CP inquires of the software vendor 15 the vendor computer, 

whether or not the software currently used by the user has The activation of an update inquiry through a demon 

been updated or improved. If yes, the new version is program is to periodically activate an update inquiry as a 

automatically purchased easily as follows. background job at night, etc. by a user at optional intervals. 

The user Uj specifies the software name Si to be inquired According to this method, unlike in the activation at the call 

for update and activates the client program CP The client 20 0 f the software, a user is free of being kept waiting when the 

program ^CP refers to user management data UD Uj) to user issues an update inquiry, 

extract the configuration ot the software Si.V currentlv used . . „ J . . 



^AutomaticReportofFaultlnformationattheAbnormal 

configuration, and sends an automatic update inquiry n 



w^ug^nv^ .uivu..^ u,,™^ u,v,o- Termination of Software 

sage To"the"vendor^""° <"""""""- "^"<">- mv-o When the software Si managed by the client program CP 



Upon receipt of the message, the server program SP 25 abnormally terminates during its operation, the client pro- 
checks the qualification of the user by referring to the user gram cp K activated immediately. The client program 
identification information based on the settings in the vendor detects the cause and condition of the abnormal termination 
management data VD (Si), and returns software update ( for example, higher-level instruction sequence which 
information to the user. The following answering process is invoked the abnormally-causing instruction), adds the user 
performed for a qualified user. 30 management data UD (Uj) (only a selected portion), and 

1. If the software has not been updated, a non-update automatically sends a fault report message to the vendor Vk. 

message is returned to the user. 2. If the software has been ^ server program SP of a vendor records the fault report 

updated, then the server program SP returns an updating message after classifying it into software Si.V, and reports 

method applied at a user site and the software required fault information to the software developer. Then, it returns 

(minimal) for update. 3. If the software is updated or „ t0 the ™™ an acknowledgement message, 

improved on a large scale, the software of a new version is Bu g s can be manually corrected by a software developer, 

recommended to the user. If th e software developer corrects a fault/bug, enters it in the 

These answering processes can be set in the vendor ob j ect software library of a vendor, and sets version man- 
management data VD (Si) by the vendor. agement information in the vendor management data Vd 

On receiving the answer message from the server program ( si ). tnen the updated version is provided as the latest 

SP, the client program CP performs an appropriate process 40 version for a user - ^ settings can be made such that the 

according to the settings in the user management data (Uj). latest version can be published only to specified or desired 

For example, when an updated software is returned, then users and can be provided experimentally, 

the software (and added information) Si.V is temporarily ( 3 ) Communications between Client Program and Server 

stored at an area specified by the user management data UD Program, and Message Configurations and Types 

(Uj), then the old version Si.V is replaced with the updated 45 The communications between the client program CP and 

software according to the update instruction information in me server program SP can be made over a network by a 

the answer message and the instruction in the user manage- method similar to electronic mail and electronic data 

ment data UD. The programs are compiled or linked if exchange EDI. 

necessary to execute the new version. (i) Up Message: A Message Transmitted from the Client 

The user can set the user management data UD (Uj) so 50 Program CP to the Server Program SP 

that, for example, an old version can be temporarily stored The configuration of an up message is as follows: 

as a backup version, and can be deleted after confirming that Addressee: a vendor name Vk at the network address of the 

a new version works successfully. vendor 

Provided is the function of automatically reporting from Sender: user name Uj at the network address of the user 

the client program CP to the server program SP as to whether 55 Subject: present software distribution/maintenance sys- 

or not the software is normally stored and updated by the t em name, command name, software name Si 

client program CP. Contents: user identification information, vendor identi- 

An update inquiry can be explicitly activated by a user, flcation information; software identification 

automatically activated when the software is invoked by a . c ,. . c , ,. 

user , or activated at a specified time (for example, every information, other necessary information dependmg on 

dawn, every week, every month, etc.) by a demon program. 60 .... * ^mmand, options, etc. 

The explicit activation by a user is to activate an update ( u > Down Message: AMessage Transmitted from the Server 

inquiry by entering an update inquiry command. For Program SP to the Client Program CP 

example, a user specifies the software to be updated in an ^ configuration of a down message is as follows: 

interactive operation, edits an update inquiry message, and Addressee: user name Uj at the network address of the 

inquires the update of the object software. The procedure of 65 user j 

an update inquiry sending process can be set in the above Sender: a vendor name Vk at the network address of the 

described user management data UD (Uj). vendor 
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CLASS 
COMMANMD 
NAME 



Contents: user identification information, vendor identi- 
fication information, software identification wantNew- 
information, other necessary information depending on wantrenew 
a command, options, etc. 
(iii) Important Message Types and Functions iQ CheckUpda 

Important types of request/inquiry up-messages and 
important down-messages answering the up-messages are BugReport: 
shown below. 



<UP MESSAGE> 



<DOWN MESSAGE> 



SUMMARY INQUIRY 
NEW PURCHASE REQUEST 
NEW SERVICE ACQUISITION 
REQUEST 
UPDATE INQUIRY 



REGULAR INSTALLATION 
REPORT 

ABNORMAL INSTALLATION 
REPORT 

TERMINATION OF USE 
SOFTWARE 



SUMMARY INFORMATION 

INITIAL SUPPLY 

SUPPLY OF NEW SERVICE 

UPDATE INFORMATION 
NO UPDATE 
ANSWERING 

RECEIVING FAULT REPORT 
IMPORTANT INFORMATION TO 
USER 

WARNING TO USER 



TERMINATION, CLEARING 



TABLE 1 



CLASS 
COMMANMD 

NAME FUNCTION OF COMMAND 



UP MESSAGE 



InstallAck: 
InstallTrouble: 

) FinishUse: 

DOWN MESSAGE 
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TABLE 1-continued 

FUNCTION OF COMMAND 



REQUEST FOR NEW PI 
REQUEST FOR ACQUISITION 
(ADDrnON) OF NEW SERVICE 
INQUIRY OF UPDATE AND REQUEST 
FOR SENDING INFORMATION OF 
UPDATED SOFTWARE 
AUTOMATIC REPORT OF RUNTIME 
FAULT INFORMATION 
MESSAGE FROM USER SUCH AS 
COMMENTS, COMPLAINTS, OPINIONS, 
INQUIRIES, ETC. 

MESSAGE OF REGULAR SOFTWARE 
PURCHASE AND INSTALLATION 
INFORMATION OF TROUBLE AT 
INSTALLATION OF PURCHASED 
SOFTWARE 
INFORMATION OF Tl 
USE 



Replylnfo: 
25 Newlnstall: 



The types of these messages can be specified ii 
mand name entered in the subject column of a 
(iv) Practical Example of a Process Command in the System 
According to the Second Embodiment 3 

According to the second embodiment, a process com- 
mand shown in Table 1 is used as a message described 



ANSWER TO INQUIRY OF SUMMARY 

INFORMATION, NEW SERVICE, 

PURCHASE METHOD, ETC. 

NEW SUPPLY OF SOFTWARE 

SUPPLY (ADDITION) OF NEW 

SOFTWARE SERVICE 

NO UPDATE ANSWER 

INFORMATION OF UPDATED SOFTWARE 

ANSWER TO USER'S COMMENTS, 

COMPLAINTS, OPINIONS, AND 

INQUIRIES 

ACKNOWLEDGEMENT OF AUTOMATIC 
REPORT OF FAULT INFORMATION 
IMPORTANT INFORMATION TO USER 
WARNING TO USER 
INFORMATION OF CLEARING USER 
OBJECT SOFTWARE PROGRAM AT 
TERMINATION OF USE 



) In the system according to the present i 
inquiry (up) message from a user is normally answered by 
an answer (down) message according to a corresponding 
important command. Furthermore, there are an exception 
process answer message and an purchase acknowledgement 

' message received from a user as an acknowledgement of 
software. 



e of important com- 



INQUIRY (UP) 



Inform (SUMMARY Replylnfo (SUMMARY 

INQUIRY INFORMATION) 

WantNew (NEW INSTA- Newlnstall (NEW INSTA- InstallAck 

LLATION /Notice LLATION) /Install- 
REQUEST) Trouble 

WantRenew (NEW Renew (ADDITION) InstallAck 

SERVICE /Notice /Install- 
REQUEST Trouble 



65 As shown in Table 2, the commands are normally 
executed as inquiries (up messages), answers (down 
messages), and acknowledgements (up messages). 
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In Table 2, a command preceded by the character / 
indicates an exception process 

A vendor exceptionally starts sending information to a 
user In this case, the information is normally limited to a 
short message only. Applicable messages are warning mes- 5 
sages and notice messages. These messages are normally 
used as a warning answer and a notice answer as an 
exception process in response to an inquiry from a user. 

Described below in detail are the contents of the above 
described up messages and down messages, and associated lQ 
user management data in user computers and vendor man- 
agement data in vendor computers. 

(a)-(c) respectively show the user identification 
information, the vendor identification information, and the 
software identification information as the contents of a 
message. In these figures, 0 indicates indispensable infor- 15 
mation; a indicates information normally required but not 
indispensable; and A indicates information required some- 
times (this is also applicable in the subsequent figures). 

(a) User Identification Information Section: 

0 user name (name within network) required 20 
0 user network address required 

□ user full name 

□ location of user (organization such as company, 
university, etc. or intra-office section) 

A location address of user 

A access to user location (telephone number, facsimile 

number, etc.) 
A position of user 

□ user entry name (contract number, member number, 30 
etc.) 

□ user password (password, private key, etc.) 

A state of user contract (contract type, starting date of 

contract, expiry date, etc.) 
A use type of user (beginner,, common user, expert, etc.) 35 

□ user computer (manufacturer, type, model, etc.) 

A user software environment (type of OS, version of OS, 
other software) 

(b) Vendor Identification Information Section: 

0 vendor name (name within network) required 40 
0 vendor network address required 
□ vendor full name 

A location of user (organization such as company, university, 
etc.) 

A location address of vendor 45 
A access to vendor (telephone number, facsimile number, 
etc.) 

A section and person in charge 

A vendor entry name (contract name, name of party etc.) 
A vendor password (password, private key, etc.) 50 
A state of contract for user (contract type, starting date of 
contract, expiry date, etc.) 

(c) Software Identification Section: 
0 software name 

□ software version type name 55 

□ software version number 

□ software version configuration date 

A software application object type name 

A software application object OS name 60 

A type and conditions of software application environ- 

A distribution range of software 
A distribution rules of software 

(1)— (19) respectively show the contents of other informa- 
tion (as messages) required for each command. 
(1) Inform (Summary Inquiry) Command 



A message: request for and inquiry of purchase 
A message; transmitting user information for selecting 
version 

(2) Replylnfo (Summary Information) Command 

O message: summary of functions, usages, effects of 
software 



□ message: request for user information required to select 

(3) WantNew (New Purchase Request) Command 

□ message: descriptions of completion of purchase pro- 
cedure and notes for process 

□ message: transmission of user information required to 
select proper version 

(4) Newlnstall (New Supply) Command 

0 detailed vendor identification information 

□ password, etc. in user identification information 
0 detailed software information 

□ specification of software application condition 
(applicable computer type, OS, environment, etc.) 

0 installation instruction information of software 
0 software configuration information 
0 body of software 

□ document, manual, etc. of software 

□ distribution rules of software 

A standard user procedure (invoked by CP) generated by 
vendor (procedure for installing, updating, and fault- 
reporting software) 

(5) WantRenew (New Service Request) Command 

□ message: descriptions of completion of purchase pro- 
cedure and notes for process 

0 specification of new service acquisition request 

□ user identification information required to select proper 

□ application for handling current software 

(6) Renew (Additional Supply) Command 

A modified portions in detailed vendor identification 
information 

A password for user identification information (only when 

modifications are made) 
0 detailed information of newly-served software (version 

type, number, etc.) 

□ specification of application condition of newly-served 
software 

0 installation instruction information of newly-served 
software 

0 configuration information of newly-served software 
0 body of newly-served software 

□ document, manual, etc. of newly-served software 
A distribution rules of newly-served software 

□ instruction and request for handling the old version of 
software 



(7) CheckUpdate (Update Inquiry) Command 

□ user identification information (computer type, OS, 
; environment, etc) 

0 detailed current software identification information 
(version type, version number, configuration date, etc.) 
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(8) Update (Update) Command 

□ explanation of software update (purpose of update, 
improved functions, newly solved problems, etc.) 

□ specification of application conditions of updated soft- 
ware 

0 detailed software identification information of updated 

software (version type, number, etc.) 
0 update instruction information of updated software 
0 configuration information of updated software i 
0 body of updated software (newly added and updated 

portions only) 

□ document, manual, etc. of updated software (updated 
portions) 

0 instruction information of processing old version of 
software 

(9) NoUpdate (No Update) Command 

A software identification information at the latest update 
(version type, number, date) 2 

(10) InstallAck (Acknowledgement of Installation) Com- 
mand 

0 identification information of received vendor message 

(vendor transmission time, etc.) 
A installation/update instruction information of installed 5 

software 

0 process type: only when automatic installation/update is 
successfully performed or temporarily stored 

(11) InstallTrouble (Unsuccessful Installation) Command 

0 identification information of received vendor message 

(vendor transmission time, etc.) 
A installation/update instruction information of installed 

software 

0 information of fault causing process 2 
A information as to whether or not temporary storage is 
performed successfully 

(12) Comment (Comment) Command 

□ message: comments, complaints, inquiries, etc. 

(13) Answer (Answer) Command 40 

□ message: answer to comments, complaints, inquiries, 
etc. 

(14) BugReport (Fault Report) Command 

□ detailed user identification information (applicable 45 
computer type, OS, environment, etc.) 

0 software identification information (version type, 

number, date) 
A software configuration information 
0 direct phenomenon and instruction relating to abnormal 50 

termination 

□ instruction strings containing the instruction which 
caused abnormal termination 

(15) BugAck (Reception of Fault Report) Command 

A direct phenomenon and instruction relating to abnormal 55 
termination 

(16) Notice (Notice) Command 

(a) Transmitted as Answer to WantNew or WantRenew 
Command 

□ message: descriptions and notes relating to purchase 
procedure and qualification restrictions 

□ message: descriptions and notes relating to software 
application restrictions 

A message: information of new services of software 65 

(b) Transmitted as Answer to CheckUpdate Command 

□ message: information of new services of software 



A message: information relating to term and renewal 
procedure for software 

□ message: information relating to counteraction against 
specific troubles of software 

(17) Warning (Warning) Command 

□ message: warning against illegal qualification 
restrictions, illegal acquisition of software, etc. 

□ message: information of legal acquisition of 
qualification, acquisition procedure, etc. 

A message: notes and warnings against specific (problem 



(18) FinishUse (Termination of Use) Command 

0 information of software version to be terminated 

□ information of process after termination of software 

(19) Erase (Clear After Termination) Command 

0 detailed object software identification information to be 

terminated (version type, number) 
0 clear instruction information of object software to be 

terminated 

□ specification of termination date of object software to 
be terminated 

FIG. 10 shows the contents of user management data in a 
user computer. The user management data are provided for 
each user. There is a single piece of user identification 
information in a set of management data, but the software 
management information and the subsequent data are pro- 
vided for each software. Although not shown in FIG. 10, the 
user management data contain a list of the names of object 
software and the version names. 

(a)-(d) respectively show the contents of the user identi- 
fication information, the software management information, 
the vendor identification information, and the software con- 
figuration information respectively in the user management 

(a)User Identification Information 

0 user name (name within network) required 

0 user network address required 



0 u 



r full n 



0 location of user (organization such as company, 
university, etc. or intra-office section) 

□ location address of user 

□ access to user location (telephone number, facsimile 
number, etc.) 

□ position of user 

0 * user entry name (contract number, member number, 
etc.) 

□ * user password (password, private key, etc.) 

□ * state of user contract (contract type, starting date of 
contract, expiry date, etc.) 

A * use type of user (beginner, common user, expert, etc.) 

0 * user computer (manufacturer, type, model, etc.) 

0 * user software environment (type of OS, version of OS, 
other software, etc.) 
(b) Software Identification Information 
0 software name required 

0 software version type name 

0 software version number 

□ software version configuration date 

□ software application object type name 

□ software application object OS name 

□ type and conditions of software application environ- 
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□ distribution range of software 
A distribution rules of software 

(c) Vendor Identification Information 

0 vendor name (name within network) required ( 
0 vendor network address required 

□ vendor full name 

A location of user (organization such as company, 

university, etc.) 
A address of vendor i 
A access to vendor (telephone number, facsimile number, 

etc.) 

A section and person in charge 

A vendor entry name (contract name, name of party, etc.) 1 

□ vendor password (password, private key, etc.) 

A state of contract for user (contract type, starting date of 
contract, expiry date, etc.) 

(d) Software Configuration Information 

0 path indicating directory storing object software 2 

□ path indicating directory storing source program 

□ module configuration in directory storing source pro- 
gram 

□ path indicating directory storing object program 2 

□ module configuration in directory storing object pro- 
gram 

□ path indicating directory storing program document 

□ module configuration in directory storing program 
document 

Table 3 shows the user call procedures (user processes) 
which can be called by the client program CP for sending a 
command to a server program SP or for receiving a com- 
mand from a server program SP. The user management data 3 
contain a list of the names of user call procedures and their 
locations which the user actually provided among the above 
listed procedures. 

TABLE 3 , 



TABLE 3-continued 



It report receptic 

living) 

ice command 

:eiving) ^ 

:eiving) 



Answer-RA 
BugAck-RA 
Notice-RA 
Waming-RA 
Erase-RA 



Command type 



summary inquiry command 

new purchase request command 

sw service supply request 

update inquiry command 
' lending) 

;omrnent command 



acknowledge command 
installation trouble commi 



Inform-SA 
WantNew-SA 
WantRenew-SA 
CheckUpdate-SA 
Comment-SA 
BugReport-SA 
FinishUse-SA 



Renew-RA 
Update-RA 
NoUpdate-RA 
InstallAck-SA 



Inform-SB 

WantNew-SB 

WantRenew-SB 

CheckUpdate-SB 

Comment-SB 

BugReport-SB 

FinishUse-SB 

Check Vendor-B 
Replylnfo-RB 

Renew-RB 
Update-RB 
NoUpdate-RB 
InstallAck-SB 



FIG. 11 shows the contents of the vendor management 
data in a vendor computer. Like the user management data, 
the software management information and the subsequent 
data are provided for each item on the list of the object 
software to be provided. 

(a)-(d) respectively show the vendor identification 
information, the software management information, the soft- 
ware configuration information, and the user identification 
information data base, in the vendor management data. The 
user identification information data base refers to the infor- 
mation about all users provided with the object software. 

(a) Vendor Identification Information 

0 vendor name (name within network) required 
0 vendor network address required 
0 vendor full name 

0 location of vendor (organization such as company, 

university, etc.) 
0 address of vendor 

0 * access to vendor (telephone number, facsimile 

number, etc.) 

□ * section and person in charge 

0 * vendor entry name (contract name, name of party etc.) 

0 * vendor password (password, private key, etc.) 

0 * states of contract for user (contract type, starting date 
of contract, expiry date, etc.) 

NOTE: * indicates that different information can be used 
about the same vendor for each object software. Thus, 
such information is stored for each object software. 

(b) Software Management Information 
0 software name required 

0 software version type name fist 
0 software version number list (for each version type) 
0 software version configuration date (for each version 
number) 

0 software application object type name 
0 software application object OS name 
0 type and conditions of software application environment 
0 distribution range of software (conditions and proce- 
dures for qualified user) 

□ distribution rules of software (conditions of users) 
NOTE: Version numbers are systematically assigned for 

respective software version types. The version pro- 
vided for each user can be identified by the version 
number. 

(c) Software Configuration Information 

0 path indicating location of object software library to be 
provided 

0 path indicating directory storing source program 

0 list of module configuration of source program of each 
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0 path indicating directory storing object program 
0 list of module configuration of object program of each 
version 

0 path indicating directory storing program document 
0 module configuration of program document of each 
version 

(d) Client Information in User Identification Information 
Database 

0 user name (name within network) required 1 
0 user network address required 
0 user full name 

0 location of user (organization such as company, 
university, etc. or intra-office section) 1 

□ location address of user 

□ access to user location (telephone number, facsimile 
number, etc.) 

□ position of user 2 
0 user entry name (contract number, member number, 

etc.) 

0 user password (password, private key, etc.) 

0 state of user contract (contract type, starting date of 

contract, expiry date, etc.) 2 
A use type of user (beginner, common user, expert, etc.) 

□ user computer (manufacturer, type, model, etc.) 

□ user software environment (type of OS, version of OS, 
other software) 3 

0 latest version type, number, and date provided for user 
A supply history to user (access date, command type, 
provided version, reception result at destination, record 
of fault report, etc.) 
Table 4 shows the vendor call procedures (vendor 3 
processes) which can be called by the server program SP for 
receiving a command from a client program and for answer- 
ing a command to the client program. The vendor manage- 
ment data contain a list of the names and their locations of 
vendor call procedures which the vendor actually provided 4 
among the above listed procedures. Vendors may have to 
perform different processes in a procedure for the same 
object software depending on the version type or version 
number. These differences can be properly processed by a 
proper logic in each procedure by performing individual A 
processes in respective cases. 

TABLE 4 



process procedure NonauthUser-A 
summary inquiry command Inform-RA 

summary information command Replylnfo-SA 

WantNew-RA 

Newlnslall-SA 

WantRenew-RA WantRene' 
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TABLE 4-continued 



Update-SA Update-SB 

NoUpdate-SA NoUpdate-SB 

Notice-SA Notice-SB 

Warning-SA Warning-SB 

tnstallAck-RA InstallAck-RB 

InstallTrouble-RA InstallTrouble-RI 



Comi 



nt-RA 



(receiving) 

report recej 



iving) 
clear after termination 
command (answering) 



Comment-RB 
Answer-SB 
BugReport-RA BugReport-RB 
BugAck-SA BugAck-SB 
FinishUse-RA FinishUse-RB 



se-SA 



se-SB 



Ice supply request 

i) 

I supply commanc 



w-SA 



CheckUpdate-RA CheckUpdate-RB 



Described briefly below are the contents of the vendor 
software library shown in FIG. 11. The software library is 
used by a vendor in the software development and 
e, and normally has a sophisticated configura- 



(a) shows an object software library; and (b) shows the 
contents of the object software development history/fault 
history data base provided for each object software library. 

(a) Object Software Library 

0 source program library of object software (including 
various version types and version numbers) 

0 object program library of object software (including 
various version types and version numbers) 

0 document library of object software (including various 
version types and version numbers) 

(b) Contents of Object Software Development History /Fault 
History Database 

0 development history information of object software 
(development date, version configuration, developed 
items, etc.) 

0 fault history summary database of object software (initial 
report date, versions and modules in problem, fault 
phenomenon, cause of fault, correction date, corrected 
item, etc.) 

□ fault report database of object software (record of date, 
user name, version, fault phenomenon, fault causing 
instruction sequence of fault report from user) 
(4) Inquiry Message Sending Process in a User Computer 
Described below is an embodiment of an inquiry message 
sending process in a user computer, 
(i) Entire Configuration of a Client Program Process in a 
User Computer 

The client program CP is stored in a user computer and 
manages the distribution and update of plural sets of object 
software used by one or more users. In response to a user's 
new purchase request, update inquiry, etc., the client pro- 
gram CP edits an up message, sends it through a network, 
receives an answer from the server program SP, and per- 
forms an appropriate process such as an installing operation. 

FIGS. 12 and 13 shows the entire configuration of the 
above described processes. The process of a client program 
is described by referring to FIGS. 12 and 13. 
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In FIG. 12, the processes according to a client program are 
shown on the left, while the user process procedure is shown 
on the right. The user process procedure is set in the user 
management data UD (Uj) set for each user. Storing the user 
process procedure in the user management data UD (Uj) and 
invoking the user process procedure in a client program 
unify the client program CP of each user. 

In FIG. 12, the client program CP is initialized in a user 
computer and set in a ready standby state (step S31 shown 
in FIG. 12). 

The client program is activated when it receives an input 
command from a user or user software, or a message from 
the server program SP over a network (step S32). 

When the client program CP is activated, then the client 
program CP analyzes data in a command column (or a 
subject column) to obtain a user name Uj, a command name, 
and an object software name Si (step S33). The succeeding 
processes, specifically the user management data (Uj) and 
the user process procedure UP, are performed for each user 
and object software. 

Then, the activator of the present client program CP is 
identified (step S34). If it is activated by a user, control is 
passed to step S35. If it is activated by user software, control 
is passed to step S36. If it is activated over a network, control 
is passed to step S39. 

If the client program CP is activated directly by a user, 
then a message edit screen is displayed in response to an 
input command and the user can edit the contents of the 
message in an interactive operation by invoking a sending 
procedure PI (step S35). 

In each sending procedure, retrieved is information 
required for each message such as a summary inquiry, new 
purchase request, new service supply request, update 
inquiry, fault report, etc. to generate a message using the 
information of the user management data UD (Uj). 

If the user software is automatically activated, then a 
message is automatically edited by invoking sending pro- 
cedure PI in response to an input command (step S36). 

User software is automatically activated through the 
above described demon program, through an instruction to 
start execution of object software, through an abnormal 
termination of object software, etc. 

If an inquiry message is generated in the processes in step 
S35 and S36, then the client program CP sends a message to 
the server program SP in a vendor computer over a network 
(step S37). 

Then, the client program CP stores the transmission of the 
message and returns to the standby state (step S38). 

If a client program is activated after receiving a message 
from the network, then control is passed to step S39 shown 
in FIG. 13, the client program refers to the message trans- 
mission record (recorded in step S38) relating the user's 
software, confirms the standby state, invokes the vendor 
confirmation procedure P2, and confirms the message sender 
(in this case, the vendor). 

The vendor confirmation procedure P2 is one of the user 
process procedures and confirms a vendor using a password, 
etc. from the vendor for the security of the user software. 

Then, in response to the command of the received 
message, a user process procedure P3 of each answering 
process is invoked (step S40). 

In each answering procedure, the software transmitted 
with an answer message is newly installed and updated by 
referring to the install instruction information in the answer 
message and the information in the user management data 
UD (Uj). If the answer message is a warning or a notice, the 
message is stored and displayed. 
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When the received message is processed, a process con- 
firmation message is generated according to the result of the 
processes in the answering procedure P3 if the process result 
is to be automatically reported, for example, in the cases 
5 when a new supply command, an additional supply com- 
mand and, or an update command is received. The generated 
message is sent to the server program SP of the vendor (step 
S41). 

Then, the client program CP stores the received answer 
1Q message, its process result, and a process result confirming 
message, and then the client program CP returns to a standby 
state in step S31 (step S42). 

(ii) New Purchase Request Message Sending Process 
Four inquiry messages actively sent by a user are Inform 

(summary inquiry), WantNew (new purchase request), 
15 WantRenew (new service acquisition request), and Com- 

The processes of the client program CP performed when 
these messages are sent are performed through steps 31-35, 
the sending procedure PI, and step S37. Described below by 
20 referring to FIG. 12 is the process of a new purchase request, 
(WantNew). 

When a user enters a WantNew command with a new 
software name Si, then a client program is activated (step 
S32). 

25 The client program CP reserves an area for the software 
name Si in the user management data UD (Uj) of the user Uj 
(if a summary inquiry has already been made, the area has 
been reserved already) so that the subsequent processes are 
performed using the user management data (step S33). 

30 The client program CP displays a message edit screen for 
a new purchase request, invokes the new purchase request 
sending procedure PI, and helps the user entering and 
editing necessary message portions (step S35). 

Set in the new purchase request sending procedure PI are 

35 the user identification information (user name, network 
address, password, etc.), software information (specification 
of software name, version type, etc.), vendor identification 
information (vendor name, vendor network address, etc.), 
and post-purchase process information (directory name to be 

40 stored, installing method, etc.). If the information has 
already been stored in the user management data UD (Uj) 
when the summary inquiry is made, then no re-entry is 
required. New information is stored in the user management 
data UD (Uj). 

45 The client program CP sends to the vendor through the 
network a new purchase request message (WantNew 
message) generated by the new purchase request sending 
procedure PI (step S37). 

Then, the client program CP records the transmission of 

50 the message, and returns to a standby state (step S38). 

(iii) Update Inquiry Message Sending Process 

The CheckUpdate message for an update inquiry is sent in 
steps 31-37 shown in FIG. 12 by the procedure PI in the 
processes shown in FIGS. 12 and 13. 

55 The update inquiry message sending method is explained 
by referring to FIG. 12. 

If a CheckUpdate command is entered with an update 
object software name specified, the client program CP 
activates the preparation for the update inquiry (step S32). 

60 The CheckUpdate command can be actively entered by 
user as described above, and can be automatically entered at 
the activation of the object software and at a timing prede- 
termined by a demon program (for example, every dawn, 
every week, every month, etc.). 

65 The client program CP performs the following processes 
using the user name UJ and software name Si as keys in 
appropriate user management data UD (Uj) (step S33). 
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The activator of the present client program CP is identi- 
fied in step S34. If it is activated by a user, control is passed 
to step S35. If it is activated by a user software, then control 
is passed to step S36. 

If the client program CP is activated directly by a user, an 
update inquiry message edit screen is displayed and an 
update inquiry sending procedure PI is invoked to retrieve 
and display information required to edit the message. At this 
time, the user can amend a part of the information, for 
example, the amendment of a version type, amendment of 
installation information, etc. (step S35). 

The update inquiry sending procedure refers to the user 
management data UD (Uj), extracts the user identification 
information (user name, network address, password, etc.), 
vendor identification information (vendor name, vendor 
network address, etc.), software management information 
(version type, current version name, current module 
configuration, etc.), and installation Information (stored 
directory name, backup instruction, etc.) to prepare for the 
generation of a CheckUpdate message. 

If the CheckUpdate command is automatically activated 
through software, then the client program CP invokes the 
update inquiry sending procedure PI and automatically sets 
a CheckUpdate message (step S36). 

When the CheckUpdate message is generated in the 
processes in steps S35 and S36, the client program CP 
automatically sends a message to the server program SP in 
a vendor computer through the network (step S37). 

Then, the transmission of the message is stored and the 
client program CP returns to a standby state (step S38). 
(iv) Fault Report Message Automatic Sending Process 

This process is performed in steps S31-S34, step S36, 
procedure PI, and steps S37 and S38 in the processes shown 
in FIGS. 12 and 13. 

The fault report message automatic sending process is 
described below by referring to FIG. 12. 

If the object software version Si.V managed by the client 
program CP abnormally terminates during its operation, a 
BugReport command is immediately transmitted to the 
client program CP (step S32). 

The client program CP detects the user name and the 
software name which caused the abnormal termination of 
the software, and the following processes are performed 
using corresponding user management data UD (Uj) (step 
S33). 

Since the client program CP is automatically activated, 
control is passed from step S34 to step S36, and the fault 
report sending procedure PI is invoked to generate a fault 
report message. 

The fault report sending procedure PI analyzes the 
instruction and the state which directly caused the abnormal 
termination and the instruction string which invoked the 
instruction which directly caused the abnormal termination. 
The fault report sending procedure PI extracts from the user 
management data UD (Uj) the user identification 
information, vendor information, and software identification 
information to generate a fault report (BugReport) message. 

When a fault report (BugReport) message is generated in 
step S36, the client program CP automatically sends the 
message to the server program SP in the vendor computer 
through the network (step S37). 

Then, the transmission of the message is stored and the 
client program CP returns to the standby state (step S38). 
(5) Process in a Vendor Computer 

Next, an embodiment of a process performed in a vendor 
computer is described below. 
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(i) Entire Configuration of a Process of a Server Program 
FIGS. 14 and 15 show the entire configuration of a 
process of a server program. The entire configuration of a 
process performed in a vendor computer is explained by 

5 referring to FIGS. 14 and 15 as follows. 

In FIGS. 14 and 15, processes performed by the server 
program are listed on the left and processes performed by 
vendor process procedures are written on the right. As 
described above, the vendor process procedure is set in the 

1Q vendor management data VD (Si) for each software library. 
Setting the vendor process procedure in the vendor man- 
agement data VD (Si) and invoking it in the server program 
allow the server program SP to be successfully unified. 

In FIGS. 14 and 15, the server program SP in the vendor 
computer is constantly activated and stands by to receive 

15 various inquiry messages to be transmitted from the client 
programs CP of a number of users through the network (step 
S51 in FIG. 14). 

If the server program SP receives a message from a client 
program CP over the network (step S52), then the server 

20 program SP checks the data in the subject column of the 
message to read a command name and a software name. The 
subsequent processes are performed for the object software 
thus specified (step S53). 
The user name and user information are extracted from 

25 the header of the message, and the vendor management data 
VD (Si) of the object software are referred to in order to 
invoke the customer confirmation procedure specified 
therein (step S54). 
A customer qualification confirmation procedure P6 com- 

30 pares the inquiring user information with the user informa- 
tion of the vendor management data VD (Si) and determines 
whether the inquiring user is a registered customer or a new 
customer. If the inquiring user is a registered customer, then 
the customer information is accessed to check the qualifi- 

35 cation of the inquiring customer. 

If the inquiring user is a new customer, the user is entered 
as a customer and assigned, for example, a summary infor- 
mation access qualification, as an initial qualification for a 
new customer. Then, it is determined whether or not the 

40 customer is qualified for a command in the received message 
(step S55). 

If the inquiring user is an unqualified user, then a unquali- 
fied user process procedure P7 is invoked and the specifi- 
cation in the vendor management data VD (Si) is referred to 

45 in order to generate an appropriate answer message indicat- 
ing rejection, warning, information how to acquire 
qualifications, etc. 

If the inquiring user is a qualified customer, the received 
message is analyzed and the inquiry is read (step S56). 

50 Then, an answer procedure P8 depending on the com- 
mand in the received message is invoked according to the 
specification of the vendor management data VD (Si) (step 
S57). 

In response to the received command, the answer proce- 
ss dure P8 retrieves necessary information to return a proper 
answer, and obtains information required to generate an 
answer message. These processes include returning sum- 
mary information, newly providing software, supplying new 
services, returning updated software information, generating 
60 other messages. 

Then, an answer message is generated using above 
described information, and information items sent to users 
are stored in the user history, etc. in the vendor management 
data VD (Si) (step 358). 
65 The answer message generated in step S58 is returned to 
the inquiry user through the network (step S59). Then, the 
server program returns to a standby state (step S60). 
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(ii) Answering Process in Response to New Purchase 
Request 

The processes of the server program SP in the answering 
process in response to a new purchase request normally 
conform to the processes shown in FIGS. 14 and 15. In these 
processes, the features of a new purchase request are 
explained as follows. 

In the customer qualification confirmation procedure P6 
shown in FIG. 14, the inquiring user is determined to be a 
qualified user only when he or she is a user who follows a 
regular purchase procedure. 

In the unqualified user process procedure P7, a method of 
following a regular procedure to make a new purchase is 
generated as a notice message to be returned. 

In the answer procedure P8, the settings in the vendor 
management data VD (Si) are referred to using the user 
identification information in the inquiry message to deter- 
mine the version type Si.V to be supplied. Then, obtained is 
a set of module Mm.l forming the latest version Si. V.l in the 
version type, and generated is the instruction information 
indicating how to perform an installation process in a user 
computer. 

In step S58, a Newlnstall message is generated as an 
answer message using the information in the answer proce- 
dure P8. 

(hi) Answering Process in Response to Update Inquiry 
Normally, this process conforms to the processes shown 

in FIGS. 14 and 15. In this process, the features of an update 

inquiry are described as follows. 

In the customer qualification confirmation procedure P6 

shown in FIG. 14, the inquiring user is determined to be a 

qualified user only when he or she is legally provided with 

the software and the condition of using the software (for 

example, the term) is still valid. 

The following processes are performed in the unqualified 

user process procedure P7. 

(a) When an inquirer is not provided with the software 
itself; 

the procedure of newly purchasing the software is 
informed of with a Notice message. 

(b) When the inquirer was legally provided with the 
software, but is not qualified after the expiration; 

the procedure for the renewal of the qualification is 
informed of with a Notice message. 

(c) When the inquirer is not legally provided with the 
software, that is, using it illegally; 

a Warning message is returned. 

In the answer procedure P8 followed in response to an 
update inquiry, determined are the version type Si.V 1 and its 
latest version number Si.V'.l" by comparing the user iden- 
tification information in the request message with the set- 
tings in the vendor management data VD (Si). 

(a) If the determined version type and number match the 
user's current version Si.V.l, then a NoUpdate message is 
returned informing that no update is required. 

(b) If the user's current version is to be updated into the 
latest version number, then a module delete/add instruction 
information is transmitted to instruct that the user's current 
version Si.V.l should be replaced with the latest version 
Si.V.l', and the required modules Mm.l' are retrieved and 
sent to the user. 

(c) If the vendor determines that the user's current version 
type Si.V should be replaced with the version type Si.V 
including a new service, then the information of the new 
version is given to the user in a Notice message. 

In step S58, an answer message is generated and the 
information about the version which is being sent to the user 
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is stored in the user individual information in the vendor 

management data VD (Si). 

(iv) Fault Report Message Receiving Process 

Normally, the process conforms to the processes shown in 
5 FIGS. 14 and 15. In this process, the features of the fault 

report message receiving process are described as follows. 
In the answer procedure P8 followed in response to a fault 

report, the contents of the fault report are properly classified, 

analyzed, stored in a fault report data base based on the 
10 vendor management data VD (Si), and then are transmitted 

to the developer of the software as a summary. The fault 

reporting user receives a BugAck message acknowledging 

the fault report. 
In FIGS. 14 and 15, the command analysis in step S54 is 
15 always followed by the generation of a new process, and the 

processes performed before the transmission of an answer 

message in step S59 are executed by the new process. Thus, 

like the client program, the server program concurrently 

performs a plurality of processes. 
20 (6) Answer Message Process in a User Computer 

FIGS. 12 and 13 show the entire configuration of the 

process of the client program CP in the user computer. 
If the client program CP sends various inquiry messages 

(refer to (4)(ii)-{iv)), the server program SP performs an 
25 answering process (refer to (5)(i)-(iv)) and returns an 

answer message. The client program CP receives the answer 

messages in the processes in steps S31-S34 shown in FIG. 

12, in steps S39-S41 in FIG. 13, and in the procedures P2 

and P3, and installs the purchased software, updates the user 
30 object software, updates the user object software, displays 

and stores Warning/Notice messages, etc. 

(i) Newly Purchased Software Installation Process 

Described below are the processes to be performed to 

receive and install a newly provided software according to 
35 the processes shown in FIGS. 12 and 13. In step S32 shown 

in FIG. 12, the client program CP receives a Newlnstall 

message from the server program SP through the network. 
The client program CP reads a user name Uj from the 

destination and a software name in the Subject column in a 
40 message, and then performs the following processes using 

the corresponding user management data UD (Uj) (step 

S33). 

Since the message is received over the network in this 
case, control is passed to step S39 (step S34). 

45 In step S39, the message transmission record relating to 
the user and the software is checked, and it is checked that 
a standby state is entered after the transmission of a new 
purchase request (WantNew) message. Then, the vendor 
confirmation procedure P2 is invoked to confirm that the 

50 message has been received from the right vendor. That is, in 
the vendor confirmation procedure P2, it is confirmed that 
the answer message is sent by a legal vendor Vk recorded in 
the user management data UD (Uj) using a password, etc. 
Then, the answering procedure P3 is invoked for a 

55 Newlnstall command by referring to the user management 
data UD (Uj) (step S40). 

The procedure of installing a newly purchased software in 
the answering procedure P3 installs the software in the user 
computer using the specification in the user management 

60 data UD (Uj) and the install instruction information from the 
vendor. If the message is determined to be rejected, then the 
contents of the answer message is stored as data only, and 
the software is not installed. The process result is monitored 
to check whether it terminates normally or abnormally. 

65 In step S41, the client program CP immediately sends the 
confirmation message of an installation process to the server 
program SP. If the installation process is normally 
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performed, or at least if the software is stored, the client 
program CP sends an InstallAck message. If the installation 
process abnormally terminates, the client program CP sends 
an InstallTrouble message. 

In step S42, the client program CP records the received 
answer message and the transmitted confirmation message, 
and then returns to the standby state S31. 

If a Notice message, instead of a Newlnstall message is 
returned after issuing a new purchase request, then the client 
program CP performs the process described later in (iii). 

(ii) Update Software Installation Process 

If update software information is received and the soft- 
ware is installed, then the above described process (i) is 
performed except the following operations. 

In step S32 in FIG. 12, the client program CP receives an 
Update message over the network. 

In step S39, the message transmission record is checked 
to confirm that the system is in a standby state after the 
transmission of the update inquiry (CheckUpdate) message 
and the message is received from the right vendor. 

The answering procedure P3 invokes an updating proce- 
dure. 

The updating procedure deletes unnecessary modules in 
the user computer using the specification in the user man- 
agement data UD (Uj) and the update instruction informa- 
tion from the vendor, and then stores added modules accord- 
ing to the received message. According to the specification 
of the user management data, the unnecessary modules can 
be actually kept undeleted, but be stored as backup data to 
enable both new version and old version to be used in 
parallel. 

The software is installed in preparation of actual execu- 
tion. If it is determined that the installation should not be 
done automatically, the software is not installed. The result 
of the updated version replacement process and the instal- 
lation process is monitored as to whether the processes 
terminated normally or abnormally. 

In step S41, a result confirmation message of the updated 
version replacement process and the installation process is 
immediately sent to the server program SP. If the processes 
terminate normally, or at least if the software is successfully 
stored, then an InstallAck message is returned. An Install- 
Trouble message is returned if the processes abnormally 
terminates. 

If a NoUpdate message is returned in response to an 
update inquiry message, then no processes are performed in 
step S40, procedure P3, and Step S41, but answer informa- 
tion only is stored in step S42. 

(iii) Notice Message Process 

A Notice message (as information only) from a vendor is 
returned as an exception process in response to various 
inquiries from a user (new purchase request, new service 
acquisition request, update inquiry, comment, fault report, 
etc.). In this case, the client program CP responds as follows. 

In step S32, the client program CP receives a Notice 
command through the network. 

In step S33, a user name, software name, and inquiry 
message are read from the message destination, Subject 
column, and In-Reply-to column. 

Control is passed from step S34 to step S39 to refer to the 
record of the transmission message and confirm that the 
answer message is received from the right vendor. 

In step S40, the type of the inquiry message is explicitly 
indicated and the answering procedure P3 for the Notice 
message is invoked. 

The answering procedure P3 displays the contents of the 
Notice message to the user, copies them to the user's mail 
box or stores them in the mail box. 



15,911 

58 

The contents of the Notice message is interpreted to take 
an appropriate action in response to the standby inquiry 
message. For example, an answer-wait state is released for 
a WantNew message and a WantRenew message. 
5 No confirmation messages are required in steps S41 and 
S42. The answer is recorded and the system enters the 
standby state. 

FIG. 16 is a simplified flowchart showing the entire 
process of the software distribution/maintenance method 

10 according to the second embodiment. Specifically, FIG. 16 
is a flowchart showing the process of the software 
distribution/maintenance method used in the software 
distribution/maintenance system according to the second 
embodiment. The operation is similar to the above described 

15 system operation, and can be briefly explained as follows. A 
client program in a user computer is activated by a user input 
command in step S61 or through a user program. Then, a 
software distribution/maintenance request message is gen- 
erated in step S62 and sent to the server program of a vendor 

20 computer. 

The server program receives the distribution/maintenance 
request message in step S63, and refers to the vendor 
software library in step S64 to generate and send to the client 
program an answer message in response to the distribution/ 

25 maintenance request message sent from the client program. 
The client program receives the answer message in step 
S65, distributes or maintains the software in step S66, and 
returns to the process in step S61 after the completion of the 
process in step S66. 

30 FIG. 17 is a flowchart showing the entire process of the 
software distribution/maintenance method using user man- 
agement data and vendor management data. As compared 
with the flowchart shown in FIG. 17, it is different in that a 
distribution/maintenance request message is generated by 

35 referring to the user management data in step S67, and that 
an answer message is generated by referring to the vendor 
management data in step S68. 

(7) Operation of Software Distribution/Maintenance System 
The software distribution/maintenance system according 

40 to the present embodiment can be applied to various ways of 
software distribution and maintenance. Described below are 
various ways of operation of the software distribution/ 
maintenance system based on the present embodiment, 
(i) Operation for Application Software Products 

45 When the software distribution/maintenance system 
described above as an embodiment is applied to distribute 
and maintain commercial application software products, the 
following operation types (in consideration of vendor man- 
agement data VD (Si) and user management data UD (Uj)) 

50 are introduced. 

(a) The vendor determines the qualifications of users as 
follows. 

Summary inquiry: All users can access summary infor- 
mation and purchase procedure. That is, every user can be 
55 informed of a contract procedure for purchasing and using 
software (including payment). 

New purchase request: On completion of the purchase 
procedure, a user is assigned a unique and authorized 
password, and the software can be provided for a user 
60 having the authorized password. 

New service acquisition request: New services can be 
provided for users who are assigned authorized passwords 
and completed new service acquisition procedure. 

Update Inquiry: Accessible by a regular customer. Other 
65 users are given a Warning message. 

(b) The vendor determines the types of versions as fol- 
lows. 
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Dependency on user models: User identification informa- 
tion should contain the model and capacity of the user 
computer so that the user can be provided with software of 
a proper version type. 

Dependency on software environment: Users are 5 
informed of the dependency on the type of operation system, 
language, etc. so that they can select proper version types. 

(c) The standard settings in the installation process in a 
user computer are listed below. 

The software is installed according to the installation 
instruction information of the vendor. 1 

An old version can be used as backup and used with a new 
updated version in parallel. 

(ii) Operation for the Operating System of a Large-scale 
Computer 

When the above described software distribution/ 15 
maintenance system is adopted to distribute and maintain the 
operating system of a large-scale computer, the following 
operations are introduced. 

(a) The vendor determines the qualifications of users as 
follows. 20 

Summary inquiry: All users are informed of summary 
information and required to follow the purchase contract 
procedure. 

Other inquiries: Only customers who are assigned autho- 
rized passwords can be answered. 25 

(b) A version type is determined between the vendor and 
the user under contract. 

(c) Described below are the standard installation pro- 
cesses in a user computer. 

The software transmitted with the vendor's message is 30 
stored in a secondary storage, and does not automatically 
activate an installation process. The installation process is 
performed by a user according to the sufficient instruction of 
the vendor. 

(iii) Operation for Shareware 35 
When the above described software distribution/ mainte- 
nance system is adopted to distribute and maintain software 

as shareware, the following operations are introduced. 

(a) The vendor determines the qualifications of users as 
follows. 40 

Summary inquiry: All users are informed of the summary 
information and the purchase procedure. The summary 
information clearly mentions that the object software is 
shareware and demands that a regular user should pay the 
fund to support the development and improvement of the 45 
software. 

New purchase request: Every user is sent the object 
software as shareware on the response of thes new purchase 
request, and the above described fund is demanded of the 
user to pay after the user's satisfaction of the software. 50 

New service acquisition request and update inquiry: 
Every entered user is informed of a new service acquisition 
request and an update inquiry. When a user issues the update 
inquiry certain times, the above described support fund is 
demanded of the user. 55 

(b) Refer to (7) (i) above for a version type. 

(c) Refer to (7) (i) above for the installation process in a 
user computer. 

(iv) Operation for Freeware 

When the above described software distribution/ 60 
maintenance system is adopted to distribute and maintain 
software as shareware, the following operations are intro- 
duced. 

(a) The vendor determines the qualifications of users as 
follows. 65 

Summary inquiry: All users are informed of the summary 
information and the purchase procedure. The summary 
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information clearly mentions that the object software is 
freeware and should be provided for other users without 
deleting the indication of the copyright. 

New purchase request: Every user is informed of a new 
purchase request, and the above description of the copyright 
handling is accompanied. 

New service acquisition request and update inquiry: 
Every entered user is informed of a new service acquisition 
request and an update inquiry. The request and inquiry. 

(b) Refer to (7) (i) above for a version type. 

(c) Refer to (7) (i) above for the installation process in a 
user computer. 

(v) Operation for Scientific Prototype Software 

When the above described software distribution/ mainte- 
nance system is adopted to distribute and maintain scientific 
prototype software, the following operations are introduced. 

(a) The vendor determines the qualifications of users as 
follows. 

Summary inquiry: All users are informed of the summary 
information and the purchase procedure. The summary 
information clearly mentions that the object software is 
scientific software and should be widely provided for other 
users with the copyright greatly respected. 

New purchase request: Every user is informed of a new 
purchase request, and is informed that the copyright should 
be respected, its commercial use is prohibited, a trial use 
report should be presented, etc. 

New service acquisition request and update inquiry: 
Every entered user is informed of a new service acquisition 
request and an update inquiry. 

(b) Refer to (7) (i) above for a version type. 

(c) Refer to (7) (i) above for the installation process in a 
user computer. 

(vi) Operation for Intra-office Developed Software 
When the software distribution/maintenance system is 

adopted to distribute and maintain intra-office-developed 
software, the following operations are introduced. 

(a) The vendor determined the qualifications of users as 
follows. ; 

Summary inquiry: Every entered member of a specified 
organization can be informed of the acquisition method. The 
information clearly mentions that other users than the mem- 
bers of the organization are not allowed to be provided with, 
use, or be presented the information. An unentered but 
authorizable user of the specified organization is informed of 
the entry method. Any user not authorizable or not of the 
specified organization is rejected with a warning message. 

New acquisition request: Every entered member of a 
specified organization can be informed of the new acquisi- 
tion request with the above described warning of no disclo- 
sure of the information to other users than internal members. 

New service acquisition request and update inquiry: 
Every entered user can be informed of the new service 
acquisition request and the update inquiry. 

(b) Refer to (7)(i) for the version type. 

(c) Refer to (7)(i) for the settings in the installation 
process in a user computer. 

It is an important nature of the software distribution/ 
maintenance system according to the present invention that 
the different ways of operation for various types of software 
are compatible and simultaneously applicable in one system. 
Such operation methods are implemented in the vendor 
management data by the vendors independently so as to 
reflect their physics of software distribution. 

Described below further in detail is the configuration and 
the process of a client program. Described first are the entire 
components in a user computer related to the client program. 
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The components are: units forming the execution environ- 
ment of the client program such as an operation system, 
network access units, etc.; the body of the client program; 
standard (default) procedures to be invoked by the client 
program; the user management data; the user call procedures 5 
in the user management data; the data area managed by the 
client program; the object software storage area, etc. 

1-15 respectively show the summary of the process 
performed by the client program. 1-15 are almost the same 
as the combination of FIGS. 12 and 13. io 

1 standby state 

2 activating by user or object software, or by receiving 
message through the network 

3 analyzing the command (user name, command name, and 
software name) and performing subsequent processes for 15 
the specified user and software 

4 jumping according to the activator passing control to 5 
when user activated CP passing control to 7 when user 
software activated CP passing control to 10 when message 
was received through network 20 

5 editing a message in interactive mode for the specified 
command invoking and using 6, then passing control to 8 

6 (each sending procedure) 

retrieving and configuring information such summary 
inquiry, new purchase request, new service supply 25 
request, update inquiry, fault report, etc. 

7 automatic editing message for each command invoking 
and using 6, then passing control to 8 

8 sending the inquiry message after recording it 

9 returning to the standby state 1 30 

10 confirming answer-wait state, and calling and using 
sender (vendor) confirmation procedure 11 

11 (vendor confirmation procedure) vendor confirmation 
process 

12 invoking answering procedure for each received 35 
command, and invoking and using 13 

13 (each answering procedure) 

installing newly purchased software and updated software 
displaying and storing warning message and notes 

14 generating and sending (only required) answer result 
confirmation message 

15 recording answer and returning to standby state 1 soft- 
ware 

An example of the process performed by the client 
program is described by referring to the summary of the 45 
process. The following explanation items 1-15 correspond 
to items 1-15 described above. 

1 The OS, network capabilities, etc. are initialized in a user 
computer. Simultaneously, the present client program 
(CP) is initialized and set in a ready standby state. Also 50 
initialized are the data managed by the client program 
(CP). 

2 The client program (CP) is activated in the following 3 
cases. 

(a) A user enters a command of the software distribution/ 
maintenance system. 

(b) The client program (CP) is activated by use's software 
or by invoking object software. 

(c) A message is received from the network to the soft- 6 
ware distribution/maintenance system. 

These processes are provided for the CP through the OS 
capabilities or the network capabilities. 

3 The summary of the activation is recognized through 
command analysis. 6 
Obtained by the analysis are the user name, the command 

name, and the software name. 
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(a) If a user inputs the command, the user specifies the 
command name and the object software name. The OS 
can supplement the user name. 

(b) If user's software or object software is activated, then 
the command name and the object software name are 
specified in the activation instruction. The user name is 
supplemented by the OS. 

(c) If a message is received through the network, then the 
user name is obtained from the destination of the 
message, and the command name and the object soft- 
ware name are obtained from the Subject column of the 



As a result of the analysis, the user management data 
(including the user-specified procedure) for the object soft- 
ware of the user are referred to in the subsequent processes. 

4 Jumping according to the activation 

In a sequential execution of the client program CP 
processes, a jump is made to 5 by a user activation; 7 by a 
user software activation; and 10 by the message from the 
network. 

In a parallel execution of the CP processes, the result of 
the command analysis is recorded in the CP operation 
history list and a child process is generated and executed 
concurrently with the parent CP program. If another child 
process is being performed for the same user and the same 
object software, the new-bom child process is kept waiting 
until the preceding child process completes. 

5 When a user inputted the command; 

The client program (CP) (or the child process of the client 
program in the parallel execution) invokes an interactive 
inquiry editing procedure 6 for the command. If the proce- 
dure is specified in the user management data, the user- 
specified procedure is used. If not, the default is the standard 
procedure. By use of the procedure, the user edits and 
generates a transmission message for the specified command 
in an interactive mode. Then, the control jumps to 8. 
7 When the client program was activated by software or a 



The client program (CP)(or the child process of the client 
program in the parallel execution) invokes an automatic 
inquiry editing procedure for the command. If the procedure 
is specified in the user management data, the user-specified 
procedure is used. Otherwise, the default is the standard 
procedure. The procedure refers to the user management 
data and automatically edits and generates an inquiry mes- 
sage for the specified command. 

8 The message generated in 5 or 7 above is recorded and 
then sent to the vendor's computer through the network. 

9 The client program (CP) returns to the standby state 1. 
The client program (CP)(or the child process of the client 

program in the parallel execution) records the transmission 
on the CP process history list. In the parallel execution of 
processes, the child process terminates its job and is deleted. 
The client program (CP) returns to the standby state 1. 

10 When the message was received through the network; 
The client program (CP)(or the child process of the client 

program in the parallel execution) refers to the CP process 
history list and confirms that the user sent a message relating 
to the object software and that the received message can be 
expected as an answer. 

To confirm that the sender of the received message is the 
right vendor, the client program (CP) or its child process 
invokes the vendor confirmation procedure 11. If the pro- 
cedure is specified in the user management data, then the 
user-specified procedure is used. Otherwise, the default is 
the standard procedure. 

If the received message is rejected by the confirmation, 
then the client program (CP) terminates without performing 
the subsequent processes and returns to the standby state 1. 
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12 Answer receiving procedure in response to a right answer 
The client program (CP)(or the child process of the client 
program in the parallel execution) invokes answer receiving 
procedure 13 for the command. At this time, either interac- 
tive or automatic answer receiving procedure is selected 5 
depending on whether the corresponding inquiry message 
was processed interactively or automatically. If the answer- 
ing procedure is specified in the user management data, then 
the user-specified answer receiving procedure is used. 
Otherwise, the default is the standard procedure. 

14 If the command requests the confirmation of the result of 10 
the answer receiving process (that is, either Newlnstall, 
Renew, or Update command), then the client program 
(CP)(or its child process in the parallel execution) auto- 
matically monitors the result of the answer receiving 
process in 13. If the answer receiving process in 13 15 
(storing and installing the software) has been successfully 
performed, then an acknowledgement (InstllAck) mes- 
sage is generated (by the user-specified or the default 
automatic editing procedure) and sent to the vendor 
through the network. If the answer receiving process 13 20 
abnormally terminates, an InstallTrouble message is gen- 
erated (by the user-specified or the default automatic 
editing procedure) and sent to the vendor through the 
network. 

15 The answering process is recorded and the program 25 
returns to the standby state 1. 

The client program (CP) (or its child process in the 
parallel execution) records the answer receiving process 
(and the transmission of the acknowledgement trouble mes- 
sage in the case of 14 above) on the CP process history list. 30 
In the parallel execution of processes, the child process 
terminates its job and is deleted. The client program (CP) 
returns to the standby state 1. 

( a Hb.) explain 6, that is, explains the processes in various 
inquiry editing procedures. The configurations of the mes- 35 
sages generated by these procedures are described above. 
Common Process 

(1) obtaining and setting user identification information 
by referring to user management data 

(2) obtaining and setting vendor identification informa- 40 
tion by referring to user management data 

(3) obtaining and setting software identification informa- 
tion by referring to user management data 

(4) generating header of a transmission message 
(destination, source, and subject columns) 45 

(b) Inform-SA/SB (sending summary inquiry) (done in 
the common process) 

(c) WantNew-SA/SB (sending new purchase request) 
(done in the common process) 

(d) WantRenew-SA/SB (sending new service request) 50 
specifying new service supply request 

(e) CheckUpdate-SA/SB (sending update inquiry) 
Detailed current software identification information 

(version type, version number, configuration date, etc.) is 55 
extracted and specified by referring to user management data 
(or the current object software if necessary). 

(f) Comment-SA/SB (sending comments) writing any 
comment 

(g) BugReport-SA/SB (sending fault report) 6 o 
Software identification information (version type, 

number, date) is extracted, and the cause and instruction 
directly involved in an abnormal termination is extracted 
and analyzed. 

(h) FinishUse-SA/SB (sending termination of use 65 
message) The version information of terminated soft- 
ware is extracted. 
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(a)-(h) explain only the main processes to be done in the 
procedures. In the automatic editing procedures, the minimal 
essence of a message is prepared, while more detailed 
portion can be specified in the interactive editing proce- 
dures. 

( a )~(i) explain the processes performed by various 
answering process procedures. 

a) Replylnfo-RA/RB (Receiving Summary Information) 

The contents of summary information are stored in a 
predetermined directory. 

(b) Newlnstall-RA/RB (Receiving Newly Supplied 
Software) 

Detailed vendor identification information, a password in 
user identification information, detailed software identifica- 
tion information (version type, number, date, etc.) are stored 
in user management data. 

The following received data of software is temporarily 
stored in a predetermined directory: 

specified software application condition (applicable com- 
puter type, 

OS, environment, etc.); software installation instruction 
information; software configuration information; body 
of software; software document and manual; software 
distribution rules; standard user procedure (to be 
invoked by CP) generated by vendor. 
After checking various application conditions specified 
by vendor, the body of software is installed according to the 
installation instruction information. 

The results of the storage and installation as to whether 
the processes are successfully performed or abnormally 
terminate should be monitored. 

(c) Renew-RA/RB (Receiving Additional Services) 

The newly served software is processed as in the case of 
the above described Newlnstall-RA/RB. The old version of 
the software should also be properly handled (i.e. either 
deleted or kept). 

(d) Update-RA/RB (Receiving Update) 

The following software update information is stored in a 
predetermined directory: 

software identification information (version type, number, 
date); 

explanation of software update (purpose of update, 

improved functions, newly solved problems, etc.); 
specification of application conditions of updated soft- 
ware; detailed software identification information of 
updated software (version type, number, etc.); 
update instruction information of updated software; con- 
figuration information of updated software; body of 
updated software (only updated and added portions); 
documents, manuals, etc. of updated software (updated 
portions); and instruction information for processing an 
old version of software. 
The above listed information is checked, and the current 
object software is updated based on the update information 
according to the update instruction information specified by 
the vendor. 

Monitored is the storage and update processes as to 
whether the processes are successfully performed or abnor- 
mally terminate. 

(e) NoUpdate-RA/RB (Receiving No Update Message) 
No action is taken. . 

(f) Notice-RA/RB (Receiving Notice Message) 

The contents of the received message are temporarily 
stored in the directory and displayed. 

(g) Warning-RA/RB (Receiving Warning Message) 

The contents of the answer is temporarily stored in the 
directory and displayed immediately. 
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(h) Answer-RA/RB (Receiving Answer) 

The contents of the answer is temporarily stored in the 
directory and displayed. 

(i) BugAck-RA/RB (Receiving Fault Report) 

The contents of the answer is temporarily stored in the 
directory and displayed. 

(j) Erase-RA/RB (Receiving Terminate And Erase Message) 
The contents of the answer is temporarily stored in the 
directory to be checked, and the information of the object 
software is cleared according to the clear instruction infor- 

(a) and (b) respectively explain 14, that is, explains the 
processes performed in the acknowledgement message 
sending procedure as a result of the answering process, 
a) InstallAck-SA/SB (Sending Acknowledgement) 

The identification information of a received vendor mes- 
sage (vendor transmission time, etc.) is extracted, and a 
message is generated according to the result of monitoring 
the installation and updating the software to inform that a 
temporary storage or process has been successfully per- 
formed. 

(b) InstallTrouble-SA/SB (sending installation Trouble 
message) 

The identification information of the received vendor 
message (vendor transmission time, etc.) is extracted, and a 
message is generated according to the result of monitoring 
the installation and updating the software to inform of the 
occurrence process of the fault and a process to be per- 
formed. 

Then, the configuration and the processes of the server 
program are described as follows. In a vendor computer, 
there are following components related to the server pro- 
gram: the execution environment of the server program 
including the operation system; the body of the server 
program; (default) procedures to be invoked by the server 
program; the vendor management data; the vendor call 
procedure in the vendor management data; the data area 
managed by the server program; the object software storage 
area, etc. 

1-14 respectively show the summary of the process 
performed by the server program. The summary of the 
process is similar to the configuration of the process for the 
server program explained in FIGS. 14 and 15. 

1 standby state 

2 receiving a message from client program over network 

3 analyzing the command of the message (user name, 
command name, and object software name) 

and performing subsequent processes for specified object 
software 

4 interpreting and storing the received message and invoking 
procedure 5 to confirm user information and user quali- 
fication 

5 performing customer qualification confirmation procedure 
as follows; 

extracting inquirer user information, 
comparing extracted data with vendor management data, 
confirming customer information for authorized customer 
and 

entering a new customer with assigning initial 
qualification, 

determining command access qualification of the cus- 
tomer 

6 in case the user is invoking unqualified user process 
procedure 7 

7 generating a message of rejection, warning, qualification 
obtaining method, etc. and passing control to 13 
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8 in case the user is qualified, invoking a receiving proce- 
dure 9 for the specified command, analyzing the received 
message, and determining a command to be returned 

10 invoking an answering procedure for the command to be 
5 returned 

11 performing the answering procedure, for the preparation 
for returning summary information, newly providing 
software, providing new service, returning update soft- 
ware information, returning other messages, etc. 

10 12 configuring the answer message and recording it 

13 sending the answer message 

14 returning to the standby state 1. 

An example of the process performed by the server 
program is explained below. The following items 1-14 

15 correspond to 1-14 shown above. In this example, a process 
of receiving a message from the client program is separate 
from a process of returning an answer message in response 
to the received message, so as to invoke the receiving 
procedure 9 and the answering procedure 11 respectively. 

20 But obviously, a receiving/answering procedure can be 
designed to perform these processes in series. 

1 The operating system and the network capabilities are 
initialized in a server computer. Simultaneously, the 
server program (SP) is initialized. After the data managed 

25 by the server program (SP) are initialized, the program is 
set in a ready standby state. 

2 When a message to the software distribution/maintenance 
system is received through the network, it is transmitted 
to the SP through the OS capabilities or the network 

30 capabilities, thereby activating the SP. 

3 The header of the message is analyzed to obtain the user 
name from the message source, and the command name 
and the object software name from the subject column. 
Used in the subsequent processes are the vendor manage- 

35 ment data (including the vendor-specified procedures) for 
the object software specified by this command analysis. 
In the parallel execution of SP processes, the command 
analysis result is recorded on the SP process history list. 
Then, a new child process is generated and executed 

40 concurrently with the parent SP program. If another 
child process is being performed for the same object 
software and for the same user, the new-born child 
process is kept waiting until the preceding child process 
completes. 

45 4 The server program (SP) (or a child process of the server 
program in the parallel execution of SP processes) first 
reads the entire received message, interprets the message, 
and temporarily stores it in a storage area of the server 
program (SP) (or the child process). The contents of the 

50 message can be user identification information, vendor 
identification information, software identification 
information, and various information required or optional 
for each inquiry/request command. Then, using the 
information, the customer qualification confirmation pro- 

55 cedure is invoked to confirm the qualification of the user. 
If the procedure is specified in the vendor management 
data, then the vendor-specified procedure is used. 
Otherwise, the default is the standard procedure. 
5 In the customer qualification confirmation procedure, the 

60 user identification information in the received message is 
compared with the user identification information data 
base in the vendor management data to determine the 
access qualification of the user. The methods of compar- 
ing and determining the related data are set by the vendors 

65 according to their distribution policy, as described later. If 
the user is a new customer, the range of the software to be 
provided for the user and the conditions of the access to 
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the provided software should be clearly defined. If the 
user is an authorized user, his or her password and access 
right to each command should be confirmed. 

6 The vendor-defined (or default) unqualified-user process- 
ing procedure 7 is invoked to handle auser who has been 5 
determined to be unqualified in the previous step. A 
message informing rejection, warning, instruction to 
acquire the qualification, etc. is returned to the unqualified 
user according to the vendor-defined rules. After returning 
the message, control is passed to 13. 

8 In response to the message received from the qualified 10 
user, the program analyzes the received message and 
interprets the contents of the inquiry from the user. To 
attain this, the vendor-defined (or default) receiving pro- 
cedure 9 is used for each command of the received 
message. In the receiving procedure, the contents of the 15 
received message are interpreted and determined by refer- 
ring to the vendor management data to select the type 
(normally a single type, but possibly plural types) of the 
command to be returned. 

10 In response to the above described determination, the 20 
vendor-defined (or default) answering procedure is 
invoked to answer the command. 

11 In the answering procedure, an answer message is gen- 
erated by referring to the contents of the received 
message, the vendor management data, and the vendor 25 
object software library. An answer message contains, for 
example, in case of an Update message, the update 
instruction information to update the software and the 
updated portion of the software. 

12 The answer message is completed with headers etc. and 30 
recorded in the SP process history list. 

13 The answer message is sent to the inquiring lient program 
through the network. 

14 (The child process is deleted here in the parallel execu- 
tion of processes.) The server program (SP) returns to the 35 
standby state 1. The customer qualification confirmation 
procedure 5 and the unqualified user process procedure 7 
are used to practically realize various vendor-defined 
software providing policy. The access qualifications of 
customers are regulated at four levels, that is, (0)-(3) as 40 
shown in Table 5. Access by a user to certain object 
software is limited to the inquiry/request commands 
shown in Table 5 depending on the four levels. There is 

a choice by the vendor, as usual for any commercial sales 
policy, between the pay-first supply-later or the supply- 45 
first pay-later policies in setting the customer qualification 
confirmation rules at level (2) for a new software request 
and a new service request command. 
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Qualification Level 



(3) access qualification of 



summary inquiry (Inform) 

new purchase request (WantNew) 
new service request (WantRenew) 
update inquiry (CheckUpdate) 



The information required for the determination of the 
access qualifications includes in addition to the basis ones 
like user identification information and software identifica- 
tion information, some information depending on each 65 
command, such as information about a payment process and 
rules, information about version selection, etc. 



The software supply rules as the contents of the customer 
qualification confirmation procedure 5 and the unqualified 
user processing procedure 7 depend on vendor's operational 
policy in distributing the software. Five operation methods 
(a)-(e) are described below as examples. 

(a) Operation Method for an OS in a Large-scale Computer 
Services are normally provided for the limited range of 

authorized users. 
Summary inquiries (level (1)) are answered in a wide 

Services of levels (2) and (3) are available for a limited 
number of users who made individual agreements. 
Therefore, the vendor enters authorized users after agree- 
ments to process the users' messages based on a strict 
password system. 

(b) Operation Method for Commercial Application Software 
Products 

All users are positively answered when they send sum- 
mary inquiries (level (1)). All accessing users are entered in 
the customer data base of the vendor; the summary infor- 
mation is arranged and returned in a format suitable for each 
user; and purchase and payment methods are specified. 

Relating to a new purchase request at level (2), answered 
are those who have promised to pay for the software (for 
example, by specifying their bank account number credit 
card number in an official format) or who have completed 
the payment for the software. Other users are answered with 
a description of payment method without providing the 
software. New service acquisition requests are answered 
likewise. 

For an inquiry at level (3), the user identification infor- 
mation such as the user name, entry number, password, 
computer model number, etc. is required and compared with 
the data in the vendor management data in order to identify 
the user as an authorized user who completed the payment. 
A user who is determined to be unqualified is so recorded 
and his or her request is rejected with a warning message. 
(The vendor can analyze the warning records later and 
legally prove that a specific user illegally obtains and uses 
the software of the vendor for a long period.) 

(c) Operation Method for Shareware 

All users who send inquiries at level (1) are positively 
answered with summary information, message which clearly 
mentions with the purchase method and the charge as 
shareware. 

For a new purchase request, the requester is entered as a 
user, immediately provided with the software, and requested 
to pay the charge later. 

For an inquiry at level (3), the inquirer is checked for his 
or her user entry (an unentered user is newly entered) and 
positively answered. If the vendor finds that the inquirer has 
not paid the charge even after certain times of update 
inquiries for a certain period, then the inquirer can be urged 
to pay the charge for the software as shareware (by use of a 
Notice message, etc.). 

(d) Operation Method for Scientific Software 
Amessage at level (1) is answered in a wide range (mostly 

for scientific users). An inquirer is answered with summary 
information of the scientific prototype software and its 
distribution policy such as the respect of copyright, prohi- 
bition of commercial use of the software, and a request for 
a trial use report. 

For a request at level (2), the requester is entered as a user, 
provided with the software, and required to accept the 
distribution rules. Normally, the software is provided free of 
charge. 

For an inquiry at level (3), the entry of the inquirer is 
checked (an unentered user is newly entered) and answered 
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positively. After the confirmation of a number of his or her 
inquiries and requests, the inquirer can be requested to 
present a trial use report, 
(e) Operation Method for Intra-office Software 

A strict check is made for an inquiry at level (1). Any 5 
access is immediately checked as to whether or not the user 
is a regular member of the organization, and the access may 
be limited to some range of members according to his or her 
position, department, and name. An unqualified inquirer is 
rejected and answered with a warning message. 1Q 

For a message or inquiry at level (2) or (3), an authorized 
user at level (1) is positively answered in most cases. The 
department and name of the user are confirmed and the user 
is allowed to access using his or her password for security. 

(a)-(t) respectively explain the receiving procedures 9 and JS 
the answering procedures 11. Each of the procedures for 
various types of received commands is primarily specified 
by the vendor. Normally, the processes are automatically 
performed, but difficult problems may be determined by the 
vendor in an interactive edit mode. Though the receiving 2Q 
procedures and the answering procedures are explained 
separately below, they can be designed to be processed in 
series as unified receiving/answering procedures. 

(a) Common Process in Receiving Procedures 

The contents of the received message have been read in 25 
step S4 in the server program (SP) and stored. Using the 
stored data, the basic portions of the received message, that 
is, user identification information, vendor identification 
information, and software identification information, are 
compared with the records in the vendor management data 3Q 
in order to complement the information required in the 
following processes and to update the record in the vendor 
management data. 

(b) Inform-RA/RB (Receiving Summary Inquiry) 

User identification information and software identifica- 35 
tion information are referred to, and the communication text 
in a received message, if any, is interpreted so that the 
answering process specifies a Replylnfo command. 

(c) Replylnfo-SA/SB (summary information returning 
Process) 4Q 

The following information of specified object software 
(for specified version type) is extracted from the vendor 
management data and the software library to edit in the 
format of communications text. 

□ summary of functions, usages, effects of the software 45 

□ descriptions of applicable computer type, OS, 
environment, etc. for the software 

□ specification of distribution policy and contract method 
for the software 

□ request for user information required to select proper 50 
version type of the software 

(d) WantNew-RA/RB (Receiving New Purchase Request) 
User information is interpreted and the vendor manage- 
ment data is referred to in order to determine the optimum 
version type for the user, and to specify a Newlnstall 55 
command in the answer message. A Notice command can be 
returned as an exception. For example, if there are no 
available versions in a user environment, the Notice com- 
mand is returned to explain the current state. If the user 
requests an old version, then the Notice command is 60 
returned to recommend a new version. 

(e) Newlnstall-SA/SB (New Supply Answer) 

The latest version of the specified version type of the 
software is newly supplied. The information in the vendor 
management data and especially the information in the 65 
vendor's software library are copied to be edited as an 
answer message. 
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O detailed vendor identification information 

□ password, etc. in user identification information 
(assigned separately in a secured method) 

O detailed software information 

□ specification of software application condition 
(applicable computer type, OS, environment, etc.) 

O installation instruction information of the software 
O software configuration information 
O body of the software 

□ document, manual, etc. of the software 

□ distribution rules for the software 

A standard user procedures (to be used by the client 
program) generated by vendor (procedures for 
installing, updating, and fault-reporting for the newly 
supplied software) 
(f) WantRenew-RA/RB (Receiving New Service Request) 
Whether or not a newly served software is provided is 
determined in a way similar to process of receiving a 
WantNew command. At this time, the treatment of the old 
software stored in the user computer is determined (by 
referring to the vendor management data). If a new service 
is not applicable a Notice command is returned as a 



(g) Renew-SA/SB (Additional Supply Answer) 

By extracting from the vendor management data and 
particularly the vendor software library, the following infor- 
mation is edited as an answer to provide the specified 
software (new service). 

A modified items in detailed vendor identification infor- 
mation 

A password for user identification information (only when 

modifications are made) 
O detailed information of the newly-served software 

(version type, number, etc.) 

□ specification of application condition of the newly- 
served software 

O installation instruction information of the newly- 
served software 
O configuration information of the newly-served soft- 

O body of the newly-served software 

□ document, manual, etc. of the newly-served software 
A distribution rules of the newly-served software 

□ instruction and request for treating the old version of 
the software 

□ instruction information of processing the old version of 
the software 

(h) CheckUpdate-RA/RB (Receiving Update Inquiry) 
The detailed information in the user's current software 

version (version type, version number, configuration date, 
etc.) is compared with the information in the latest version 
of the vendor management data, and it is determined 
whether or not the software needs to be updated. At this 
time, if the user identification information in the received 
message (computer type, OS, environment, etc.) is found, 
changed from the record in the vendor management data 
(changed at a user site), or if the criterion of the version 
selection is changed by the vendor, then an appropriate 
version type should be selected. 

In a normal update process (including a small-scale 
change to another version type), an Update command is 
specified as the answer. If no update has been made, then, a 
NoUpdate command is chosen as the answer message. If a 
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large-scale change in version type or a change into a new (o) Comment-RA/RB (Receiving Comment) 

service is recommended, a Notice command (not an Update The message is recorded in the software supply history of 

command) is chosen as the answer message. the user in the vendor management data, and displayed in an 

(i) Update-SA/SB (Update Information Answer) interactive mode to ask the vendor for an appropriate 

The following information is edited as an answer to 5 processing. An Answer command is used in the answering 

update from user's current software version to the specified process. 

VerS10n - (p) Answer-RA/RB (Answering Process) 

□ explanation of updating software (purpose of update, In response t0 a user < s Comment command> an answer 
improved functions, newly solved problems, fixed ^ message ^ generated in an interactive mode by the vendor 

ugs, etc.) t0 answer various questions and complaints. 

D software 1 ' 011 ° f appHcati ° n conditions of the u P dated (q) BugReport-RA/RB (Receiving Fault Report) 

_^ . The contents of the received message are recorded in the 

O detailed software identification information of the fault report history database and transmitted to the vendor. 

updated software (version type, number, etc.) JS Specifically, if similar fault reports are not stored in the fault 

O update instruction information of the updated software report history database and the fault is determined to be a 

O configuration information of the updated software new lv P e > tnen a warning message is given to the vendor's 

O body of the updated software (newly added and is engineer in charge. NormaUy, a BugAck command is used 

updated portions only) m the answer message. 

□ document, manual, etc. of the updated software 20 W BugAck-RA/RB (Fault Report Receipt Answer) 
(updated portions) A regular message just indicating the receipt of a fault 

□ instruction information of processing the old version of f p0rt * edited automaticallv - 

the software ( s ) FinishUse-RA/RB (Receiving use Termination) 

(deletion through replacement, reserving for a prede- The message is recorded in the software supply history of 

termined period, etc.) the user in the vendor management data. Commercial and 

G) NoUpdate-SA/SB (Answering Without Update) technical procedures are determined for the use termination 

A NoUpdate command is specified in an answer message. °f tne specified software version. If the termination is 

A software identification information at the latest update appropriate, then a terminate-and-clear answering procedure 

(version type, number, date) 30 is specified, 

(k) Notice-SA/SB (Note Answer) (t) Erase-SA/SB (Terminate-and-clear Answer) 

The following messages are edited (for each case) accord- Clear instruction information is edited by specifying the 

ing to the results of the receiving process. identification information for the specified software version, 

descriptions and notes relating to purchase procedure and An expiry date of the use of the object software to be cleared 

qualification restrictions 35 may be specified at this time, 

information relating to term and renewal procedure for Described finally are practical examples of using the 

software software distribution and maintenance system according to 

descriptions and notes relating to software application the second embodiment of the present invention. The present 

restrictions system aims at being used widely as a general-purpose 

information relating to counteraction against specific 40 system and aUows t0 be implemented with sophisticated 

troubles of the software technologies at vendor computers and user computers, 

information of new services of the software Expl^d below, however is the second embodiment real- 

(1) Warning-SA/SB (Warning Answer) Ked wlth rather sunple we U-known element technologies. It 

A Warning message is issued from the unqualified user * DOtlCed * at ! he P resent invention * not Kmited b ? such 

process procedures in most cases, but can also be issued as 45 element techno10 ^- 

a warning by answering procedure as an exception in an ( a ) Slm P le Practical Embodiment of Configuration of Soft- 
emergency. ware and Generation of Update Information (1) 

For example; First, an object software SI comprises one version type 

if a user uses the object software in an undesirable 50 VY1 containing a plurality of modules Ma, Mb, Mc, 

environment and a serious fault is expected unless (al) Configuration and Management of Software in Vendor 

proper correction is made. Computer 

if a renewal procedure is recommended because the In a vendor computer, the software library SI of the 

expiry is closing down. software (for example, in a UNIX system) is stored under a 

if a serious fault is detected in the vendor software and 55 single directory named, for example, directory S1.VT1. The 

restrictions of use should be placed on the user. source program of each of modules Ma, Mb, Mc, ... is put 

An answer message is generated depending on the above as a single file in the directory. Each module is represented 

listed conditions. by a module name (Ma, Mb, etc.) followed by its version 

(m) Install-Ack-RA/RB (Receiving Acknowledgement) number (1, 2, . . . ) as a complete file name (for example, 

The acknowledgement is recorded in the software supply 60 Ma -1» Mt >.3, etc.). The version number of each module is 

history of the user in the vendor management data. No incremented by 1 each time it is amended or updated, 

answering process is performed. The easiest method of managing the versions of a soft- 

(n) InstallTrouble-RA/RB (Receiving Installation Trouble ware library is to always store a single set of the latest 

Message) modules. If a module or a set of modules) is updated, the 

The message is recorded in the software supply history of 65 version number of the software is incremented by 1. Accord- 

the user in the vendor management data, and is shown to the ing to this method, the software version and the internal 

vendor's engineer in charge. configuration of the modules are as follows, for example. 
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code modules are provided, then the object-code modules 

are managed in a way similar to the source-code programs 

Module Configuration in the above example. 

~~~ — (a3) Update Inquiry and Update Instruction 

Mbi Mc2 Mdi 5 With-these settings, the automatic update of the software 

Mb.2 Mc.3 Md j Me.i ca " be relied as follows. 

Mb.2 Md.i Me.2 Mf.i Th e easiest method is to indicate the version number of 

'. the software assigned by the vendor when the client program 

of a user computer issues an update inquiry (in a CheckUp- 
In the vendor management data managed by the software date message). In the example above, the version name 
vendor according to this method, the information of the io consists of the software name, version type name, and 
software configuration is as follows, for example. version number (for example, S1.VT1.1, S1.VT1.3, etc.). In 



S1.VT1.1 
S1.VT1.2 
S1.VT1.3 
S1.VT1.4 



list of provided object software: 

list of version type names of software: 
list of version number of software: 
date of version configuration of software: 
location of software library: 
Home directory of source program: 
list of module configuration of source 
program of each version: 



SI 
SI 
VT1 

1. 2, 3, 4 

931005, 931108, 931227, 940131 

home/Si 

home/Sl/VTl 

S1.VT1.1 = (Ma.l, Mb.l, Mc.l, Md.l), 
S1.VT1.2 = (Ma.2, Mb.l, Mc.2, Md.l), 
S1.VT1.3 = (Ma.2, Mb.2, Mc.3, Md.l, Me.l), 
S1.VT1.4 = (Ma.3, Mb.2, Md.l, Me.2, Mf.l) 



To manage an object code program as well as a source, 
code program of software, a source code module name is 
followed by .s (for example, Ma.l.s) as an extension, and an 
object code module name is followed by .o (for example, 
Ma.l.o). The associated, document of the software is 
divided into modules appropriately, and managed in ver- 3 
sions such that a set of documents can be referred to 
corresponding to each version of the software. 
(a2) Management of Software in User Computer 

When the above described object software is provided for 
a user, the easiest method of managing the object software 3 
is to store and use the latest version of the object software 
in the user computer. In the user management data of each 
user, the information of the configuration of the object 
software can comprise as follows. 



this case, the update inquiry message is composed as follows 
(detailed user identification information is omitted here) 

To: Vendor-Sl@Vendor.co.jp 

From: Userl@chem.sci.tokyo-u.ac.jp 

Subject: sdmp: CheckUpdate SI 

Message: 

Software: (Current- Version: S1.VT1.1) 
Upon receipt of the message, the vendor's server program 
(SP) recognizes that the user's current version name 
(S1.VT1.1) is different from the vendor's latest version 
name (S1.VT1.4), and edits the information for update. To 
attain this, the information of module configuration of the 
' i the vendor management data are used to 



a list of object software names ar 

software name: 

software version number: 
software version configuration dai 
software location directory: 
source program location dir 
source program module con 



If a i 



a list of object software names and 

software name: 

software version type name: 

software version configuration date: 
software location directory: 
source program location directory: 
source program module configuratio 



SI (S1.VT1.3), software 



931227 
home/Si 
home/Si 

Ma.2, Mb.2, Mc.3, 
Md.l, Me.l 



lf.1) 



The body of the object software is stored in modules just 
as specified in the above described user management data. 
As shown in this example; if source-code programs are 65 
provided, they are compiled in the user computer into 
object-code modules and are stored together. If only object- 



Only modules requiring additional data are transmitted to 
the user together with the difference information as update 
) instruction information. In this example, an update com- 
mand to be returned is written as follows. 
To: Userlchem.sci.tokyo-u.ac.jp 

From: Vendor-Sl@Vendor.co.jp Subject: SDMP: Update 

SI 
Message: 

Software: (Current- Version: S1.VT1.1) 
Updated-Software: 

(Description: "A bug was fixed and two new functions are 
1 added." 

Version-Type: VT1, Version-Number; 4, Version-Name: 

S1.VT1.4 
Version-Date: 940131 
Modules: (Ma.3, Mb.2, Md.l, Me.2, Mf.l) 
Update-Direction: (Delete: (Ma.l, Mb.l, Mc.l), 
Add: (Ma.3, Mb.2, Me.2, Mf.l)) 
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Number-of-Files-Attached: 4) 
Treatment-of-Old-Software: Delete 
Files- Attached: 

source program file of module Ma.3 

source program file of module Mb.2 5 

source program file of module Me.2 

source program file of module Mf.l 

Upon receipt of the update message, the user's client 
program interprets the message, and by referring to the user 
management data, it updates the object software, and then N> 
updates the user management data itself As a result of the 
update, the new user management data of the user becomes 
as follows. 



SI (S1.VT1.4), 
software of other 
vendors, etc. 
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software version type name: 
software version number: 
software version configuration 
software location directory: 



(b) Simple Practical Embodiment of Configuration of Soft- 
ware and Generation of Update Information (2) 

An example of a little more complicated configuration of 
software is considered next. Object software S2 has two 
version types VTa and VTb, and each version type has a 
plurality of modules and shares a part of them with each 
other. To properly maintain and manage the software library, 
the vendor stores all the old versions of modules as well as 
the latest versions. 

(bl) Configuration and Management of Software in Vendor 
Computer 

In the vendor computer, the software library SL of the 
software S2 can be stored in a single directory (for example, 
S2. VTab) for the two version types together. Each module is 
identified by a module name and a module version number 
(for example, Ma.l, Mb.3, etc.) as in (a). 

Corresponding to the two version types, two series of 
versions are generated, and the software library is required 
to store the version names and the module configurations of 
respective version types in a time series as follows. 



According to the update instruction information in the 
received message, the client program by invoking the update 
receiving procedure updates the modules of the software 
using received module files. That is in the above example, 
three modules Ma.l, Mb.l, and Mc.l are deleted from the 30 
current modules and newly added are four modules Ma.3, 
mb.2, Me.2, and Mf.l. 

In this case, the old version of the software is not stored. 
(a4) Update Inquiry and Update Instruction (Another 
Method) 35 

The method of (a3) is based on the vendor's storage of the 
module configuration information for all the versions, and 
users only have to enter the current version names. An 
alternative method is to send from a user to the vendor the 
current module configuration information independently of 40 
the version name (or as a complement of version name 
information). 

the example above, an update inquiry 
■ can be composed as follows (detailed 
is user identification information is 45 



Corresponding t 
message from a us 
information such 
omitted). 

To: Vendor-Sl@Vendor.co.jp 

From: Userl@chem.sci.tokyo-u.ac.jp 

Subject: SDMP: CheckUpdate SI 

Message: 

Software: (Current- Version: S1.VT1.1) 
Current-Modules: (Ma.l, Mb.l, Mc.l, Md.l) 
Upon receipt of the message, the vendor's server program 
(SP) compares the set of the user's current modules with the 
latest version set of vendor's modules to obtain the differ- 
ences. 



931005 S2.VTa.l Ma.l Mc.l S2.VTb.l Mb.l Mc.l 

931108 S2.VTa.2 Ma.2 Mc.2 S2.VTb.2 Mb.l Mc.2 

931227 S2.VTa.2 Ma.2 Mc.2 S2.VTb.3 Mb.2 Mc.3 Me.l 

940131 S2.VTa.3 Ma.3 Me.2 S2.VTb.4 Mb.2 Me.2 Mf.l 



The software library also stores the old version of modules 
for maintenance (normally the software library packs the 
entire data to store only the original version of each module 
and the difference data. Therefore, the entire stored modules 
(in a restorable packed format) are the following 11 mod- 



Modules are used either exclusively in a specific version 
type or commonly among a plurality of version types. 

In the vendor management data, the information about the 
software configuration can be stored as follows. 

a list of object S2 

software name: S2 

list of software VTa, VTb 

version type names: 

list of software (VTa:) 1, 2, 3 

version numbers: (VTb:) 1, 2, 3, 4 

software version (VTa:) 931005, 931108, 

configuration date: 940131 

(VTb:) 931005, 931008, 

931227, 940131 
location of software home/S2 

source program (VTa:) home/S2/VTab 

location directory: (VTb:) home/S2/VTab 

list of source program module (VTa:) 



= (Ma.l, Mc.1), 
= (Ma.2, Mc.2), 
- (Ma.3, Me.2), 



Subsequently, an update instruction message is generated 65 
and sent by the vendor, and on receiving the message the 
software is updated by the user by the same method as (a3). 



= (Mb.l, Mc.1), 

- (Mb.l, Mc.2), 

- (Mb.2, Mc.3, Me.l) 
= (Mb.2, Me.2, Mf.l) 
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(b2) Dependency on Applicable Environment and Selection 
of Version Type 

In a set of software, a plurality of version types are 
required (or appropriate) in the following cases, 
different software functions in the same applicable environ- 
ment (various functions) 
a number of new function added to the original software in 

the same applicable environment 
different capacities of main storage in the same applicable j 

computer model, OS, and software environment 
different applicable software environment (for example, 
input/output interface software, database interface, runt- 
ime library, etc.) in the same applicable computer model, 
OS, etc. l 
different OS (for example, due to level up) in the same 

applicable computer model 
hardware-dependency due to different applicable computer 

model in the same OS 
different applicable computer model and OS 2 

The software vendor provides a plurality of version types 
to properly adopt the software to these differences and is 
requested to select and provide an appropriate version type 
depending on the situations of each user. To attain this, the 
vendor clearly describes and informs the users of the appli- 2 
cable range of each version type, incorporates selection logic 
in the vendor management data and the vendor procedures 
and obtains from the users enough information enough to 
select appropriate version types. For example, the following 3 , 
vendor management data are set for the two version types for 
(bl). 

applicable computer model for software: 

(VTa:) A100, F3, H20, S1000 3 

(VTb:) A200, F3, F4, S1000, S1500 
applicable OS for software: 

(VTa:) OS-A.1.3, OS-F3.2, OS-S.3.1 

(VTb:) OS-A.1.4, OS-F3.2, OS-F3.3, OS-S.3.3 4I 
types and conditions of applicable environment for software: 

(VTa:) Graphics-1, Memory ^4 MB 

(VTb:) Graphics-1 or Graphics-2, Memory §8 MB 

The vendor procedure refers to these data to determine an 4 , 
applicable or an appropriate version type for each user. 
(b3) Software Management in User Computer 

Normally, users only have to store the latest version of an 
appropriate version type for their environment. The configu- 
ration information object software in the user management 51 
data is almost the same as that in (a2). For example: 
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-continued 



a list of object software names an 



version type name: 
version configuration date 



Mb.2, Me.2, Mf.l 
F4 

20 MB 
OS-F.3.3 
Graphics-1 



i list of object software ns 



software name: 
software version type name: 
software version number: 
software version configuratioi 
software location directory: 
source program location direc 
:e program module confij 



applicable c 



home/S2 
Ma.2, Mc.2 
A100 



(b4) Update Inquiry and Update Instruction of Software 

The client program (CP) of a user has to perform almost 
the same processes as (a3) in an update inquiry for the 
software. For example, for the above described user who 
stores the version S2.VTa.2, the update inquiry message is 
generated as follows. (The user environment information is 
omitted in (a3), but is added below.) 
To: Vendor-S2@Vendor.co.jp 
From: UserA@docs.sci.tit.ac.jp 
Subject: SDMP: CheckUpdate S2 



Software: (Current- Version: S2.VTa.2) 
User: (User-Machine: A100, Main-Memory: 10 MB, 
OS: OS-A.1.3, Software-Environment: Graphics-1) 
Upon receipt of the message, the server program (SP) of 
the vendor checks the environment of the user to confirm 
that an appropriate version type is used by the user. Then, it 
is determined whether or not the version maintained by the 
user is the latest version of the version type. If not, the 
difference between the modules is obtained as in (a3) or (a4). 
latest version of type VTa S2.VTa.3 =(Ma.3, Me.2; 



The server program (SP) returns an Update command 
message, providing the user with the above described dif- 
ference information sent as update instruction information 
together with the body of modules to be added. The user 
client program (CP) receives the answer message and 
updates the software S2. All these methods are the same as 
in (a3). 

(b5) Update Beyond Version Type 

In (b4), software is updated within the same version type. 
Described below is the method of updating software beyond 
the version type boundary in the same object software. There 
are cases in which the software is updated beyond version 
type. For example: 

The vendor starts providing the software of a new version 
type though the user environment remains unchanged 
(adding functions, developing a level-up version, releas- 
ing restrictions, etc.). 

Software environment of the user is appropriately improved 
to solve new problems by using a better version type of 
the vendor software, though the user computer model and 
the applicable OS remain unchanged. 
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A new higher-level 05 is introduced in the user computer to 
obtain a necessary software environment and use a level- 
up version of the object software, while the user's com- 
puter model remains unchanged. 

The user has introduced a higher-level computer model and : 
OS, and requests an improved version of the object 
software. 

For example, suppose that the two above mentioned users 
refer to the same user who switches his or her environment 
from that of version S2.VTa.2 to that of a new version i 
S2.VTb.4. That is, the user's environment is switched as 
follows. The changes in the computer model and OS enable 
the conventional version type VTa to be upgraded into 
another higher-level version type VTb. 



computer model: A100 -» F4 

main storage capacity: 10 MB 20 MB 

OS: OS-A. 1.3 - OS-F3.3 

environment software: Graphics-1 -» Graphics-1 

With the change in the computer model and OS, the user 
expects an updated and higher-level version of the software. 
Thus, the user enters an update inquiry command in the 
client program (CP) to edit his or her user identification 
information with the interactive editing function, and sends ' 
the following update inquiry message. 

To: Vendor-S2@Vendor.co.jp 

From: UserA@docs.sci.tit.ac.jp 

Subject: SDMP: CheckUpdate S2 ; 
Message: 

Software; (Current-Version: S2.VTa.2) 
User: (User-Machine: F4, Main-Memory: 20 MB, 
OS: OS-F3.3, Environment-Software: Graphics-1) 
Upon receipt of the message, the server program (SP) of ; 
the vendor checks the environment of the user to confirm 
that the user environment has been changed from that 
recorded in the vendor management data, and then updates 
the contents of the vendor management data. In the new user 
environment, it is confirmed that a higher-level version type 1 
VTb is applicable. The switching of the version type is 
automatically performed as follows (assuming that the 
switching of the version type does not demand extra 
payment). 

The server program (SP) obtains the difference from the 4 
user's current version to the latest version of the new version 
type VTb. 



Version-Name: S2.VTb.4 
Version-Date: 940131 
Modules: (Mb.2, Me.2, Mf.l) 
Update-Direction: (Delete: (Ma.2, Mc.2), 

Add: (Mb.2, Me.2, Mf.l)) 
Number-of-Files-Attached: 3 
Treatment-of-Old-Software: Keep for one month 
Files- Attached: 

source program file of module Me.2 

source program file of module Me.2 

source program file of module mf.l 

Upon receipt of the update message, the user's client 
program interprets the message, refers to the user manage- 
ment data, updates the user management data, and then 
updates the object software to generate a new version 
S2.VTb.4. Since the change in the object software is 
significant, the old version of the software (version 
S2.VTa.2) is not deleted completely, but is allowed to keep 
and use for a back-up purpose for one month as indicated by 
the update message. As a result of the update, the user 
management data of the user reads as follows. 



S2 (S2. VTb.4, S2. VTa.2), 



m S2. VTb.4:) 



software name: 
software version type name: 
software version number: 
software version configuration date: 

source program location directory: 
source program module configuration: 
computer model: 
main storage capacity: 



jrogram location directory: 



VTa 
2 

931108 

home/S2/old 

home/S2/old 

Ma.2, Mc.2 

A100 

10 MB 

OS-A.1.3 

Graphics-1 



er will nc 



The update message in return is sent as follows. 
To: UserA@docs.sci.tit.ac.jp 
From: Vendor-S2@Vendor.co.jp 
Subject: SDMP: Update S2 



Software: (Current- Version: S2. VTa.2) 
Updated-Software: 

(Description: "Due to your environment change, Version 

S2. VTb.4 is now installed. 
New features are . . . " 
Version-Type: VTb, Version-Number: 4, 



are stored in the shared file st 
software can still be useful.) 

(b6) Update Beyond Version Type (2) Providing New Ser- 

The process in (b5) above refers to the update beyond 
i version type, but is automatically performed under the 
situation that the update process does not impose extra 
charge on the user. On the other hand, there are cases when 
the update beyond version type refers to an upgrade to a new 
service which requires the user to pay extra charge. In this 
) case, the server program returns a Notice message to prompt 
the user for his or her decision. If the user requests the 
purchase of the new service, then the user sends a WantRe- 
new message. In this case, the user and the vendor commu- 
nicate messages and perform the necessary processes as 
; follows. 

As in (b5), the user sends the CheckUpdate message with 
the change in the computer model and OS. The server 
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program recognizes that the version type required for the number of sets of software provided by different software 
model and OS is a newly served version imposing an extra vendors needs to be served by separate and different soft- 
charge on the user. Thus, it returns the following Notice ware vendors needs to be served by separate and different 
message. software distribution/maintenance systems. For improving 
To: UserA@docs.sci.tit.ac.jp 5 this situation on the user side, the software distribution/ 
From: Vendor-S2@Vendor.co.jp maintenance system according to the second embodiment of 
Subject: SDMP: Notice S2 tne P resent invention is built to handle a plurality of sets of 
Messase- object software in a unified way by overcoming the prob- 

S " lems Of Variations 



Software: (Current-version: S2.VTa.2) 10 For the purpose of ^p^g this situation on the ^ 
Notice: "Due to your environment change, a new-service side, the software distribution/maintenance system accord- 
version S2.VTb.4 is to be used. Please follow the ing to the second embodiment of the present invention is 
renewing procedure described in the attached file, and built to handle a plurality of sets of object software in a 
issue a 'WantRenew' message." unified way. Thus, from the viewpoint of a user, it can be 
Number-of-Files- Attached: 1 15 regarded as a one-user * many-(one-software-one-vendor) 
Files-Attached: system. By combining the viewpoints of users and vendors, 
Upgrading the software from version S2.VTa to version tne system can be regarded as a many-user *many-(one- 
S2.VTb software-one-vendor) system. 

(A document file describing new functions, applicable In a wider viewpoint, this system certainly accepts the 

environment, purchase procedure, and WantRenew 20 situation that one set of object software having a number of 

command) version types are developed and distributed by a number of 

Upon receipt of the Notice command, the client program vendors and are used on various types of platforms. Thus, 

first stores the command and displays the message to the rae software distribution/maintenance system according to 

user. The user reads the contents of the message and docu- me second embodiment of the present invention forms a 

ment files. After following the procedures of the payment for 25 unified system of a many-user * many-software * many- 

the purchase, the following WantRenew command is issued. vendor * many-platform type. 

To: Vendor-S2@Vendor.co.jp Since the networks of computers are already built and 
From: UserA@docs.sci.tit.acjp operated in global scales, it is naturally expected that the 
Subject: SDMP: WantRenew S2 SoftW " e distribution/maintenance system according to the 
J 30 second embodiment of the present mvention can serve as a 
essage. unified infrastructure system for the distribution and main- 
Software: (Version-type: VTb tenance of software in the world-wide scale, if its protocol 
Current- Version: S2.VTa.2) is internationally standardized. Thus the system and method 
User: (User-Machine: F4, Main-Memory: 20 MB, according to the present invention are expected to have 
OS: OS-F3.3, Environment-Software: Graphics-1) 35 innovative effects on the systems and methods of software 
(c) Practical Example of Fault Report System distribution and maintenance, in a similar way that the 
An example of an automatic fault report was explained as electronic mail system and method had innovative effects on 



the first embodiment by referring to FIG. 7. the mailing systems and methods. 

The following description complements the explanation. As described above, the software distribution/ 

When the object software terminates abnormally, the oper- 40 maintenance system according to the second embodiment of 

ating system (OS) normally detects the abnormal termi- the present invention is a generalizing extension of the 

nation and find out the cause of the abnormal termination software distribution/maintenance system according to the 

(that is, no "/bin/play" command to be executed is found) first embodiment of the present invention. In the first 

and the source of the cause ("ISISinfo"). embodiment, a single set of object software is to be distrib- 

The system should be set such that the client program can be 45 uted and maintained. Thus, a user who uses a number of sets 

automatically by the OS activated and the above infor- of software provided by different software vendors needs to 

mation is automatically informed of when an abnormal be served by separate and different software distribution/ 

termination occurs. maintenance systems. For improving this situation on the 

To trace back the executed instructions from the one which user side, the software distribution/maintenance system 

directly causes an abnormal termination. It is a function of 50 according to the second embodiment of the present inven- 

a debugger in a programming language and to locate the tion is built to handle a plurality of sets of object software 

source codes of the sequence of the instructions. in a unified way by overcoming the problems of variations. 

There are not many language systems which provide this The effects of the second embodiment of the present 
function in a form available to other programs, but Lisp invention are summarized below briefly: 
and tcl/tk are the examples of having such a function. The 55 Concerning to one set of software distributed and main- 
example is obtained using the tracing function of the tcl/tk tained by a vendor for a large number of users, the effects of 
language for the object software written in tcl/tk. the second embodiment of the present invention include all 

A fault report message is generated in the format of normal the effects of the first embodiment of the present invention, 

electronic mail and sent to the server program through the That is, for maintaining the object software in a user 

network. 60 computer, an update inquiry message is automatically sent 

As described above, the software distribution/ by the client program to the vendor on the simple activation 

maintenance system according to the second embodiment of either by the user's command input, by the activation of the 

the present invention is a generalizing extension of the Object software, or by the instruction of user 's software 

software distribution/maintenance system according to the such as a daemon program; as the answer to it, an update 

first embodiment of the present invention. 65 instruction message is automatically composed and returned 

In the first embodiment, a single set of object software is by the vendor's server program to the user; and then, on 

to be distributed and maintained. Thus, a user who uses a receiving the answer, the client program automatically 
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updates the object software. A fault report is also automati- 
cally sent to the vendor on the occasions of abnormal 
user/vendor procedures for specific handling of different 
types of messages. 

Such standardized structure of the server/client programs 5 
has an important effect to standardize the protocols for the 
software distribution/maintenance. (This point may be com- 
pared to the standardized structure of the electronic mail 
program, which can handle messages with standardized 
header and arbitrary contents.) The second embodiment of 10 
the present invention thus can form a basis of such stan- 
dardized protocols. 

In concert with the growth of networks in the global 
scales, the software distribution and maintenance system 
according to the second embodiment of the present inven- 15 
tion is expected to make a worldwide infrastructure system 
for software distribution/maintenance. The effect of such a 
system gives innovative impacts on software industries, user 
industries, and whole range of users, organization and indi- 
vidual. 20 

According to the technique of the second embodiment, a 
method to resolve the problems 1 through 4 is proposed. 
However, a new problem arises in the second embodiment, 
which also existed implicitly in the first embodiment. 

As shown in FIG. 8, a client program is expected to 25 
handle a number of object software systems of one or more 
users in the second embodiment. For the client program, for 
example, it is required to design to handle a plurality of 
pieces of object software for a plurality of users. Therefore, 
it is complicated. Especially, an interface to call the user 30 
process procedure (UP), and handling of parallel processing 
when a user requests a plurality of processes are difficult. 
The similar problem may arise in the server program SP. 

The object of the third embodiment is to distribute soft- 
ware on a worldwide scale, or build a standardized technical 35 
framework suitable for a form of software distribution 
without making the designs of the client program CP and the 
server program SP complicated. That is, the present inven- 
tion is intended to provide software distribution and main- 
tenance system and method, which uses a plurality of and a 40 
variety of pieces of software as objects and can be utilized 
by a plurality of and a variety of software users linked on a 
worldwide scale over a communications network between 
computers, and comprises a capability to rapidly and prop- 
erly acquire and use software created and updated by soft- 45 
ware vendor. 

FIG. 18 is a block diagram showing a principle of the 
present invention. In this figure, 81 through 83 are user 
computers, 84 and 85 are vendor computers, and 86 is a 
general-purpose network for connecting the user computers 50 
and the vendor computers. 

The user computers 81 is used by a user Ul. The user 
computer 82 is used by users U2 and U3. The user computer 
83 is used by a user 4. The vendor computers 84 and 85 are 
generally each used by one software vendor, and are respec- 55 
tively used by the vendors VI and V2. Generally, one or 
more object software applications (software applications as 
objects for distribution and maintenance, which generally 
correspond to one or more users) are installed in the user 
computers. Management data for user UD and the first 60 
process program CP, for example, are installed for each 
object software application. 

On the user computer 82, for example, object software 
applications S2.b and Sl.c are installed for the user U2, 
management data for user and the client program CP are 65 
installed for each object software, and object software S2.a, 
the management data for user U2, and the client program CP 
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are installed for the user U3. SI and S2, for example, 
distinguish object software applications, and a, b, and c 
indicate their versions or (version types). 

The first process program, the client progran (CP), for 
example, handles only one piece of object software for one 
user. It uses dedicated management data for users UD and 
user process procedures (UPs), to be described later, to 
distribute and maintain the object software. That is, it sends 
various messages such as a software purchase request made 
by a user to a vendor, an update inquiry, a fault report, etc., 
made by a user to a vendor and performs processes such as 
an update of user software etc. after receiving an answer 
message from the vendor. When sending and receiving 
messages, the client program executes these processes based 
on standardized protocols of the software distribution/ 
maintenance system. 

The management data for user UD, consisting of user 
identification information, vendor identification 
information, software management information, etc., is used 
when processes such as sending messages, updating user 
software, etc. are performed by the client program CP. 

The vendor computers 84 and 85 are each utilized by one 
vendor. Inside the vendor computer 4, for example, software 
libraries SL (SI) and SL (S2) are installed, and correspond- 
ing management data for vendor VD and the second process 
program, the server program SP, for example are installed 
for each library. The software library SL (SI) generally 
consists of a plurality of versions (or version types) of the 
object software SI. For example, the software library SL 
(S3) in the vendor computer 85 consists of two versions (or 
version types) S3.a and S3.b of the object software S3. 

The management data for vendor VD, consisting of 
information such as vendor identification information, user 
management information, software management 
information, etc., is utilized by, for example, the server 
program SP. 

The server program SP handles only one object software 
library for one vendor, similar to the client program CP 
installed on the user computer, and performs distribution/ 
maintenance of the object software using the dedicated 
management data for vendor VD and vendor process pro- 
cedures (VP), to be described later. 

A network 86 is a general-purpose network, which allows 
message communications between the client program CP 
installed on the user computer and the server program SP 
installed on the vendor computer. By standardizing 
protocols, messages of the software distribution/ 
maintenance system can be sent/received between the user 
and the vendor. The network 86 may be connected all the 
time, or connected depending on need similar to an elec- 
tronic mail connection to send and receive messages. 

In FIG. 18, the user computer and the vendor computer 
are generally different to each other. Some of the computers 
are, however, used by a user serving as both a user and a 
vendor. Therefore, one computer may sometimes include 
both the client program CP and the server program SP. In 
this case, the client program CP and the server program SP 
behave in exactly the same manner as they behave individu- 
ally. 

As described above, the vendor manages a number of 
versions of one piece of software to provide them to a 
number of users. The user takes advantage of one version of 
each software and a number of types of software (provided 
by different vendors) at the same time. Thus, the present 
invention is based on the assumption that a number of 
versions and types of the object software are provided by a 
number of vendors and used by a number of users. 
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Further explanation on the principle of the present inven- 
tion is given below, referring to the FIG. 18. The software 
distribution and maintenance system using a network that a 
number of users Ul, U2, . . . using a number of types of 
object software SI, S2, . . . to be distributed, managed, and 5 
maintained, and a number of software vendors supplying the 
above object software manage the distribution and mainte- 
nance of the above object software over a computer network, 
comprising: 

(a) one or more first process programs, CPs, installed in each 10 
of user computers 81 through 83, that manage object 
software groups SI, S2, . . . to be used by the users Ul, 
U2, . . . individually for every object software and for 
every user using the object software; 

(b) one or more second process programs SPs, installed in is 
either of software vendor computers 84 or 85, that gives 
services to vendor software libraries SL(S1), SL(S2), . . . 
for each of the software libraries; 

(c) a network 6 that connects the first process program CP 
installed in the user computer to the second process 20 
Oprogram SP installed in the vendor computer, based on 
standardized communications protocols; 

(d) a capability that performs distribution and/or mainte- 
nance for the above object software by sending a message 
that requests to distribute and/or maintain the object 25 
software for one piece of object software via the network 
86, according to instructions given by the users Ul, 
U2, ... or a user-defined program, receiving an answer 
message from the second process program SP, and 
depending on the contents of the answer message and 30 
settings made by the user Ul, U2, . . . ; and 

(e) the second process program SP that has a capability to 
reference the software libraries SL(S1), SL(S2), . . . 
managed by the vendors VI, V2, . . . depending on the 
contents of a received message and settings made by the 35 
vendor VI, V2, ... for the object software specified with 
the message when receiving the above message from an 
arbitrary first process program CP, to generate an answer 
message to request distribution and/or maintenance of the 
above object software, and to send the answer message to 40 
the first process program CP of the sender of the corre- 
sponding message. 

Next, the software distribution and maintenance method 
according to the present invention is explained below. 

In FIG. 18, the users Ul, U2, . . . specify desired software 45 
(object software) and its vendors VI, V2, . . . and invoke an 
acquisition inquiry instruction, the first process program CP 
then sends a purchase inquiry message to the software 
vendors VI, V2, . . . . 

The second process program SP, corresponding to the 50 
object software library installed on the software vendor side, 
receives this message, verifies a qualification of the user, 
automatically performs an appropriate process depending on 
settings of the management data for vendor VD, and returns 
an answer message to the user. 55 

The first process program CP that sends the purchase 
inquiry message receives the answer and advises the user. If 
the software itself is returned, the first process program CP 
stores it according to instructions included in the answer 
message. 60 

Then, the first process program CP references the man- 
agement data for user UD, and performs required compila- 
tion and linking, etc. based on settings of that data so that the 
software can automatically be installed in a pre-specified 
area. 65 

Additionally, the first process program CP makes an 
inquiry about whether or not an update or improvement is 
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made for software currently used by the users Ul, U2, . . . 
If the software is updated, the users Ul, U2, . . . specify a 
desired software name to be updated and requested, and 
invoke the first process program CP. After the first process 
program CP references the management data for user UD to 
extract a configuration of the software Si.v that the user is 
currently using, it sends an automatic update inquiry mes- 
sage with the user identification information appended to the 
vendors VI, V2 

When a corresponding second process program SP 
receives this message, it verifies a qualification of the user 
according to the settings of the management data for vendor 
VD, and returns update information about the software. To 
a qualified user, a message of "no update" is returned as 
update information such as when the software is not 
updated. If the software is updated, messages of "an update 
method for a user side" and "the software itself for an 
update" are returned. 

When the above reply is received, the first process pro- 
gram CP firstly stores, for example, the updated Osoftware, 
according to the settings of the management data for the 
user, replaces a previous version with the updated version 
according to update instructions received, etc. It performs 
compilation and linking if needed, to allow execution of the 
updated version. As an invocation method for an update 
inquiry, an invocation by a user, an automatic invocation 
when the user calls a software, an invocation at a specified 
time (for example, the start of every day, every week, every 
month, etc) is made by a demon program. 

If software installed on the user computer managed by the 
first process program CP abnormally terminates while 
running, the first process program detects a cause and a state 
of the fault and automatically sends a fault report to the 
vendor VI, V2, 

A corresponding second process program SP registers this 
and reports it to a developer. In addition, it returns a message 
acknowledging a receipt of the message to the user. 

After software bugs are manually fixed by the developer, 
the software is registered in an object software library of the 
vendor. After that, the update version is provided to the user 
as the latest version. 

Further explanation on the software distribution and 
maintenance method implemented with the present inven- 
tion is given below with reference to the FIG. 18. 

The above software distribution and maintenance system 
performs the following processes: 

(a) Each user Ul, U2, . . . invokes a first process program CP 
corresponding to one piece of object software by entering 
a command on the user computer Ul, U2, ... or by 
invoking a command from a user-specified program; 

(b) the first process program CP sends a message to request 
distribution and/or maintenance of the object software to 
a corresponding second process program Sp via a network 
86; 

(c) the second process program SP receives the message 
from the above first process program CP on the vendor 
computer for the above object software; 

(d) references the software library managed by the vendor 
VI, V2 based on the contents of the received message and 
the settings of the object software specified by the 
message, generates an answer message to request distri- 
bution and maintenance of the above object Osoftware, 
and returns the above answer message to the first process 
program CP of the user that sent the corresponding 
message via the network 86. 

(e) The first process program CP receives an answer mes- 
sage from the above second process program SP on the 
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user computer Ul, U2, . . . in the sender side of the above 
message, and performs the distribution and/or mainte- 
nance processes for the above object software based on 
the contents of the reply and settings of the user Ul, 

U2 5 

As described above, the present invention installs the first 
process program, for example, the client program, on the 
user computer for every object software and for every user. 
The invention also installs the second process program, for 
example, the server program SP, for every software library 
on the vendor computer. By executing a message transfer 10 
between the client program CP and the server program SP 
based on standardized protocols, a standardized software 
distribution and maintenance system and method can be 
implemented on a very large scale, for example, on a 
worldwide scale though the method is primarily proposed 15 
for each software. 

Description of the Preferred Embodiments 
(1) System Structure and the Network 

FIG. 19 is a block diagram showing an embodiment of the 
software distribution and maintenance system that takes 20 
advantage of a communications network implemented with 
the present invention. In this figure, a user computer 91, a 
vendor computer 93, and a user/vendor computer 94 are 
connected over a network 92. Compared with FIG. 18, that 
shows a principle of the present invention, there is a basic 25 
difference in FIG. 19 that the user/vendor computer 94 is 
used by a user serving both as a user computer and a vendor 
computer for software. The user/vendor computer 94 is 
equipped with a client program CP for the software to be 
used as a user, and a server program SP for a software library 30 
SL (S3) to be provided as a vendor. 

Further compared with FIG. 18, there is another differ- 
ence in FIG. 19 that a user process procedure group (UP) 
corresponding to each client program CP, and a server 
process procedure group (VP) corresponding to a server 35 
program (SP) are added. Details of these groups are 
described later. 

The present invention comprises a capability to send and 
receive messages between the client program CP installed in 
the user computer and the server program SP installed in the 40 
vendor computer. Detailed explanation of the above capa- 
bility is given below: 

This invention is based on the assumption that message 
communications can be performed between the client pro- 
gram (CP) of a certain ,user managing one piece of object 45 
software, and the server program (SP), managing a corre- 
sponding software library of the vendor supplying the object 
software. Such communications capability is one of basic 
capabilities of a network. 

A specific name can be used for a process that performs 50 
a group of operations on each computer (the above CP and 
SP can be in a form of processes) under an operating system 
(OS). With this technique implemented (on a user computer, 
for example), a specific process name can be created for 
each client program (CP), which should be composed of the 55 
combination of a client program name of the system of the 
present invention, the user name, and the object software 

Meantime, a network system (the internet system, for 
example), recognizes a process on each computer, and 60 
generally provides transmission from each process to 
outside, and reception from outside computers to each 
process. If a network address of an other computer con- 
nected to the network is given, a message can be sent to that 
computer. 65 

Accordingly, by specifying a network address computer 
and a name of process in the receiver side, and by repre- 



senting a message based on an appropriate network com- 
munications protocol, a message can be sent from a process 
installed in one computer (a client program, for example) to 
a process installed in another computer (a server program, 
for example) by taking advantage of the capabilities of the 
operating system (OS) and the network system. Thus, peer- 
to-peer communication can be implemented between the 
client program and the server program. 

Of course, a main process that handles communications 
made by a plurality of client programs (CP) on each com- 
puter can be set. In this case, the main process handles 
message transmission and reception processes in parallel. 
Processing of distribution and parallel processing are 
required in this case. A destination address of the commu- 
nication message is represented by the network address of 
the partner computer and the main process is represented as 
a partner process. 

However, a message processing (especially, a parallel 
processing and a distribution processing) performed in the 
main process, is similar to a basic processing performed in 
a communications network. Thus, it is not a matter whether 
such processing is performed in the main process or in the 
general-purpose network. (Furthermore, it is an intention of 
the present invention to let the general-purpose operating 
system (OS) and the network system perform such process- 
ings as described above, instead of the main process that 
explicitly performs them.) 

As described above, when process groups exist in each 
computer, communications between peer to peer can be 
performed as well as communications between group to 
group by use of established techniques. 

According to the object of the present invention, a com- 
munications method implemented with the present invention 
is simply expressed as a method of "communications 
between processes over a general-purpose network", which 
may be either in peer to peer or in group to group performed 
in a ratio of 1 to 1 and a ratio of group to group. 

(2) A Function of the System of the Third Embodiment 
This function is similar to that of second embodiment and 

its explanation is abbreviated. 

(3) Kind and Structure of Messages 
The kind and function of the messages and the command 

set used in the third embodiment are similar to those of the 
second embodiment, and the explanation is also abbreviated. 
The structure and syntacs of the messages in the third 
embodiment are described below. 

(3.1) Structure of 'Upward Messages' (from Users to 
Vendors) 

The 'upward messages' from users to vendors have the 
following st 
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(3.2) Structure of 'Downward Messages' (from Vendors to 
Users) 

The 'downward messages' from vendors to users have the 
following structure: 



user's name and network addres 
vendor's name and network add 
SDM system name, SDM conm; 
name, and name of the target 



inquiry/request message 



new/updated version of ft 
target software 
requirements of 
user's hardware/software 



As the topmost keywords of the attributes part, we choose 
the four keywords of 'user', 'vendor', 'software', and 'envi- 
ronments'. 

10 The instruction part may also be written in the form of 
keyword-and-value lines. For example, the instructions to 
add modules and to delete modules are written in this form. 
The keywords to be used in the instruction part may depend 
on the command of the message. 

15 The module part may also be written (within a textual 
representation) in the form of 'module: (the body of a 
module)'. 

One advantage in specifying the messages in the form of 
the keyword-and-value pairs is that the specified information 
may be stored in its original form (or after re-assigning the 
keyword) in the user management data (UD) or in the vendor 
management data (VD). Once the system of keywords is 
clearly defined in their names and semantics, the informa- 
tion stored in the form of keyword-and value pairs can 
readily be searched, updated, and analyzed. 
25 (3.4) Hierarchical Structure of Keywords 

As described above, the messages are described in a 
hierarchical scheme of keyword-and-value pairs. A hierar- 
chical system of keywords is chosen in the following way: 
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(3.3) Syntacs of the Messages 

The syntacs of the upward and downward messages is 
described here in the human readable textual form. Actual 
coding of messages on the network may depend on the 5 
network system. 

The specifications of the receiver, the sender, and the 
command line in the header part of the message are always 
necessary. They are written line by line in the form of 
keyword-and-value (or value list) pairs using a delimiter 5 
such as a colon in between. 

The attributes part is similarly written with lines of a 
keyword-and-value pair. In case the specification of the 
value is complex, the complex value may be written by a 
group of keyword-and-value lines enclosed in parentheses. 60 delete™ 011 treatment 

In a manner similar to programming languages, we may add 
define various delimiters: such as parentheses and semico- (module part) 

Ions for explicitly define a list of values (these may be module 

replaced by spaces in an implicit but clear case of a list of " 

values), a CR for a line break, a '/'mark (or Yen mark in 65 (4) Process Performed on a User Computer 

Japanese) for line continuation, etc. Thus, it may be A client program (CP) is installed on a user computer to 

described in the following manner: manage an acquisition and update of one piece of object 



version type 
configuration 
description 



payment 



5,835. 

91 

software by one user. This program edits an upward message 
and sends the edited message via a network when operations 
such as a request for a new acquisition or an update inquiry, 
etc. are performed by a user. It receives a reply from a server 
program (SP) to perform installation, etc. An entire flow- s 
chart of the process is shown in FIG. 23, and each step of the 
process flow is described below. 
Step S71: 

A client program (CP) is invoked when a command is 
entered by a user or by user software (a demon program, 10 
etc.), or when a command is entered at an invocation of the 
object software. 

Step S72: 

The client program calls a user process procedure to 
interactively or automatically edit an inquiry/request mes- is 
sage when the command is entered. Within the user process 
procedure, a message is generated by referencing and 
searching management data for user (UD). Message types 
are a summary inquiry, a request to newly acquire new 
software, a request to receive a new service, an update 20 
inquiry, a fault report, etc. 
Step 573: 

The client program registers a message and sends it to a 
corresponding server program of a vendor via a network, 
and waits for a reply message. To keep confidentiality for 25 
communications, a portion or a whole of the message is 
sometimes encrypted before being sent. 
Step S74: 

The client program receives a reply message from the 
server program (S) of the vendor via the network. 30 
Step 575: 

The client program calls the user process procedure for a 
reply message (UP) P3, and verifies that the reply message 
is sent from the legal vendor using management data for user 
(UD). When a portion or a whole of the received message is 35 
encrypted, the program decrypts it using an appropriate key 
to prove that both the user and the vendor are legal. 
Step S76: 

The client program calls a user process procedure for a 
reply message reception when receiving the message com- 40 
mand. Reception messages are summary information, new 
supply information, addition information, an update, a non- 
update, a notice, a warning, a reception of fault report, a 
comment answer, etc. The user process procedure (UP) 
analyzes the received message and stores its contents. When 45 
determined to be appropriate, installation is performed 
according to instructions being sent by the vendor to per- 
form processes such as an update of management data for 
user (UD). These processes reference and update manage- 
ment data for user (UD) and object software. 50 
Step S77: 

When an automatic report of a result of a received 
message process is desired (in case of a new supply, an 
additional supply, and an updated message), a result of a 
process performed in Step S76 is monitored. An installation 55 
verification message or an installation error message is 
respectively returned to the server program (SP) of the 
vendor if the process is properly executed, or if a problem 
arises. Step S78: 

The client program registers the reception of the reply 60 
message and a result of the process, returns a control to the 
process that calls the client program (CF). Then, the program 
is terminated (enters into an idle state). 

The process of the client program (CP) described above 
basically conforms to those of the first and the second earlier 65 
applications. There are, however, the following differences 
in particular. The difference from the first earlier application 
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is that the client program (CP) calls the user process pro- 
cedures (UP) (by adopting the method of the second earlier 
application), to make it clear that the management data for 
user (UD) is used. While the difference from the second 
earlier application is that no sorting or parallel processings 
are required for a plurality of users and a plurality of types 
of object software management since the client program 
(CP) manages one piece of object software for one user, 
which allows simplification of the processes when receiving 
an answer message or when entering a command (likewise 
the first earlier application). 

(Note that the parallel and sorting processing can be more 
generally performed as capabilities of an operating system 
(OS) and a network due to the existence of a plurality of 
client programs (CPs). Therefore, it may not be processed 
within the software distribution and maintenance system of 
the present invention, and the above simplification can be 
implemented.) 

(5) Process Performed in a Vendor Computer 

A server program (SP) is installed on a vendor computer 
to distribute and maintain object software of each vendor. 
Inquiry /request messages such as a request for a new soft- 
ware purchase, an update inquiry, etc., are sent from a 
number of client programs of users over a network. The 
server program (SP) receives these messages, generates an 
answer message for services such as a new software supply, 
update information, etc., and returns them in response to the 
request made by the client program over the network. 

An entire flow of the message process performed by the 
server program (SP) of the vendor is shown in FIG. 24. Each 
step in the figure is described below: 
Step S81: A server program (SP) installed in a vendor 
computer is always invoked to wait for receiving various 
messages of inquiry /request sent by a client program (CP) 
over a network. 
S82: The server program receives a message from a client 
program (C?) over the network. (Normally, a sub-process 
is created to process a message performed in steps S83 
through S87. The main process of the client program 
reenters a standby state. There is no distinguishing 
between the main process and the sub-process for 
simplicity.) 

Step 383: The server program extracts a user name and user 
information from the messages, and calls a vendor pro- 
cess procedure (VP) for user qualification verification 
Pll. With the user qualification verification VP, user 
information is verified to determine whether or not the 
user is qualified to perform an access with this command, 
using management data for vendor (VD). 

Step S84: For an unqualified user, the server program calls 
an unqualified user process procedure (VP) P12, and 
generates an appropriate answer message such as a 
refusal, warning, information about acquiring 
qualification, etc. After that, the processing goes to Step 
S86. 

Step S85: For a qualified user, the server program calls a 
vendor process procedure for a reception/answer process 
(VP)P13 corresponding to a command included in a 
received message, and generates an answer message to the 
user. The answer message is created according to the 
protocols of the software distribution and maintenance 
system. 

The vendor process procedure (VP) analyzes the received 
message, extracts information from the vendor management 
data and the object software library to be provided, and 
generates a message. Additionally, it stores the provided 
contents, etc. in the user information included in the vendor 
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management data (VD). There are such any 
types as a summary information supply, a new software 
supply, a new service supply, a message of update 
information, a message of no update, a comment answer, etc. 
There are additional message types such as a Notice 5 
message, warning message, etc. as exceptions. 
(6) Usage 

Basic usage and operation methods of the third embodi- 
ment of the present invention are similar to those of the 
second embodiment; thus the explanation of them is abbre- 10 
viated. The following way of using the persent invention is 
new and suitable to the third embodiment of the present 
invention. 

Bootstrapping of the Client Program 

So far in our description of the embodiments of the 15 
present invention, we assume that users already own the 
software components (i.e., a client program (CP), user 
procedures (UPs), etc.) of the present software distribution 
and maintenance system when they want to get a new target 
software system. Some standard client program (CP) and 20 
user procedures (UPs), which we propose in our second 
embodiment of the present invention, may be obtained 
earlier in some conventional way such as with a portable 
media or with ftp. However, for making the software dis- 
tribution and maintenance system in the present invention 25 
better fit to each target software, the CP and UPs should 
better be designed for the target software by the vendor and 
be supplied to the users 'beforehand'. This is particularly 
intended and desirable in our third embodiments of the 
present invention. 30 

This problem is readily solved. By the use of the present 
invention, users can obtain from vendors, with minimal 
preparation and burden, a new target software system and a 
set of CP and UPs which best fits for the distribution and 
maintenance of the target software, in the following steps: 35 
Step 1: A user has to prepare a minimal set of CP and UPs 
which has the function of sending an Inform message for 
summary information inquiry and of processing the Reply- 
Info message to be received in reply. We may assume that 
this minimal set of CP and UPs is provided in public as a 40 
standard tool and is easily obtainable in any traditional way 
of software distribution. 

Step 2: By use of the minimal set of CP and UPs, the user 
now sends an Inform message for obtaining summary infor- 
mation of any target software he wants. 45 

The vendor sends back a Replylnfo message which con- 
tains the summary information of the target software and a 
basic set of the present software distribution and mainte- 
nance system sufficient for newly requesting the target 
software. The basic set may include: a basic CP, user 50 
procedures(UPs) for sending a WantNew message and 
receiving its reply, and user management data(UD) useful 
for composing the WantNew message. 
Step 3: By means of the basic set of software distribution 
and maintenance system supplied above, the user may send 55 
a WantNew message to the vendor to request the target 
software. 

In response, when the vendor returns a Newlnstall mes- 
sage for newly supplying the target software, the vendor 
provides the user with a full set of the present software 60 
distribution and maintenance system which is built best fit to 
the target software. The full set may contain the whole of the 
client program (CP), a full set of user procedures (UPs), and 
instructions to install these CP and UPs. 
Step 4: Now the user can use the full set of the user's 65 
components of the software distribution and maintenance of 
the present invention; by using it, he can easily update and 
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renew the obtained target software in the manner described 
so far. The method described here may be used further for 
the vendor of the target software to maintain the software 
distribution and maintenance system itself at the user's site. 

This example of embodiment clearly shows that the 
software distribution and maintenance system suitable for 
the target software can be composed on users' computers 
without any burden of users and that the distribution and 
maintenance of various target software can be achieved 
readily by use of the present invention. 

One problem of the second embodiment of the present 
invention is the complexity in constructing the standard 
client program (CP) which invokes different sets of user 
procedures(UPs) for handling a variety of object software 
systems. The interface between the CP and UPs needs 
careful design and can not be flexible. A solution to this 
problem has guided us to the third embodiment of the 
present invention as described above. The solution compro- 
mises the ideas of the first and second embodiments and 
takes advantages of them both. The third embodiment of the 
present invention adopts the simplicity of the first embodi- 
ment by limiting to handle only one target software system, 
while it adopts the whole ideas of the second embodiment to 
overcome the variation problems; they include clear sepa- 
ration among the client program (CP), user procedures 
(UPs), user management data (UD), and target software and 
the standardization of the message protocols. 
Effects of the Third Embodiment 

The effects of the third embodiment of the present inven- 
tion are summarized here briefly: 

The choice that the client program (CP) handles a single 
target software for a single user has released the CP's burden 
of complexity in the multitask processing of possibly many 
target software systems and many users. This makes the CP 
simple to handle one inquiry/request from the user at one 
time. 

The same choice has reduced more significantly the CP's 
burden of complexity in adapting to the variation in target 
software and in user. The CP is constraint by the standard 
message protocols to communicate with the server program 
SP, but has full flexibility inside. Namely, the CP invokes its 
own user procedures (UPs) and the UPs access to the user 
management data (UD) and the target software. Thus, whole 
set of these CP, UPs, UD, and target software can be 
designed in a set according to the principles of the present 
invention; interfaces among them may be chosen flexibly 
and appropriately for each target software, without being 
constraint of the choices for other target software. 

This has simplified the design of the CP, Ups, and UD, and 
has made the present invention much feasible and practical 
for wide variety of target software. 

The proposal of message protocols for software distribu- 
tion and maintenance in the third embodiment of the present 
invention is also an important step towards establishing such 
a standard. The message types used in the second embodi- 
ment of the present invention are used and the syntacs of the 
messages are made clearer by the definition of a hierarchy of 
keywords to be used in the keyword-and-value presentations 
of information. Such a definition of protocols needs to be 
examined further in the practice. 

As described so far, the choice of single target software in 
the third embodiment does not mean to set back the software 
distribution and maintenance method in the present inven- 
tion to be useful only for the specified target software. 
Rather, the choice makes the present invention widely 
applicable to any software system as its target of service. 
The client/server systems according to the third embodiment 
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of the present invention may be constructed and used by 
various vendors to serve their users. Since the methods for 
users to use them are standardized as described in the present 
invention, users can use such software distribution and 
maintenance systems as if they were a standardized tool 5 
without noticing the differences inside them. 

Just as described as the effects of the first and second 
embodiments of the present invention, the effects of the third 
embodiment of the present invention are expected to be 
innovative in the distribution and maintenance of software. 10 
Once vendors develop and update the software for service 
on vendors' computers, huge number of user in the global 
scales can obtain and use the new and corrected versions of 
software almost immediately on users' computers without 
burdens of labor and skills in obtaining and installing them. 15 
The software distribution and maintenance systems of the 
present invention take care of the automatic or semi- 
automatic communication between the users' and vendors' 
computers through the networks. The users may not notice 
the users' software systems are corrected automatically in 20 
this manner of network service. The rapid growth of the 
network in the global scale will nake the services of software 
distribution and maintenance according to the present inven- 
tion useful and indispensable in the global scale. 

What is claimed is: 25 

1. A software distribution/maintenance system having a 
plurality of user computers and a vendor computer con- 
nected to the user computers via a network to manage and 
automatically update over the network a set of object 
software sent and stored in the user computers from the 30 
vendor computer via the network, comprising: 

an object software library in the vendor computers; 

first process means in the user computers for sending an 
inquiry with current configuration information of the 
object software stored in the user computers to the 35 
vendor computer via the network to inquire about a 
latest configuration, for receiving an answer from the 
vendor computer, and for updating the object software 
stored in the user computers according to an instruction 
in the answer; and 40 

second process means in the vendor computer for receiv- 
ing the inquiry from said first process means in the user 
computers, for generating update instruction informa- 
tion for the object software to match the current con- 
figuration of the object software in the user computers 45 
with the latest configuration of an updated version in 
said object software library stored in the vendor 
computer, and for returning via the network to said first 
process means the answer with the update instruction 
information and the updated version of the object 50 
software. 

2. The software distribution/maintenance system accord- 
ing to claim 1, wherein said first process means in the user 
computers automatically informs via the network the vendor 
computer of an abnormal termination and state if an opera- 55 
tion of the object software abnormally terminates in the user 
computers. 

3. The software distribution/maintenance system accord- 
ing to claim 2, wherein said first process means automati- 
cally informs the vendor computer of the abnormal 60 
termination, an instruction causing the abnormal 
termination, a reason for the abnormal termination, a series 

of instructions which invoked the instruction causing the 
abnormal termination, and an environment of software and 
hardware used when the abnormal termination is detected. 65 

4. The software distribution/maintenance system accord- 
ing to claim 2 or claim 3, wherein said first process means 
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can automatically inform, via the networks the vendor 
computer of the abnormal termination by general-purpose 
electronic mail. 

5. A software distribution/maintenance method for man- 
aging and automatically updating a set of object software 
stored in user computers from a vendor computer via a 
network, comprising: 

sending, by a first process in the user computers, current 
configuration information of the object software to a 
second process in the vendor computer via the network 
with an inquiry for a latest configuration of the object 
software; 

receiving by said second process in the vendor computer 
the inquiry from said first process; 

generating update instruction information for the object 
software to update a configuration of the object soft- 
ware in the user computers with the latest configuration 
of an updated version of the object software in an object 
software library stored in the vendor computers; 

returning via the network to said first process an answer 
with the update instruction information and the updated 
version of the object software; and 

processing by said first process stored in the user com- 
puters the answer from said second process to update 
the object software according to the update instruction 
information in the answer, including preparing for 
compiling and linking of programs if necessary. 

6. The software distribution/maintenance method accord- 
ing to claim 5, wherein when the object software is activated 
in the user computers, said first process 

immediately sends the current configuration information 
of the object software to said second process in the 
vendor computer via the network to inquire about the 
latest configuration, 

receives the answer from said second process, 

updates the object software according to the update 
instruction information in the answer, and 

prepares for compiling and linking programs if necessary. 

7. The software distribution/maintenance method accord- 
ing to claim 5, wherein when said first process is activated 
in the user computers at a predetermined time, said first 
process 

sends the current configuration information of the object 
software to said second process in the vendor computer 
via the network to inquire about the latest 
configuration, 

receives the answer from said second process, 

updates the object software according to the update 
instruction information in the answer, and 

prepares for compiling and linking of programs if neces- 
sary to realize an automatic update of the object soft- 

8. The software distribution/maintenance method accord- 
ing to claim 5, wherein when a user instructs the user 
computers to activate said first process, said first process 

sends the current configuration information of the object 
software to said second process in the vendor computer 
via the network to inquire about the latest 
configuration, 

receives the answer from said second process, 

updates the object software according to the update 
instruction information in the answer, and 

prepares for compiling and linking of programs if neces- 
sary. 
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9. The software distribution/maintenance method accord- 
ing to claim 5, wherein following processes are interchange- 
ably performed: 

when the object software is activated in the user 
computers, said first process 5 
immediately sends the current configuration informa- 
tion of the object software to said second process in 
the vendor computer via the network to inquire about 
the latest configurations, 
receives the answer from said second process, 10 
updates the object software according to the update 

instruction information in the answer, and 
prepares for compiling and linking programs if neces- 

when said first process is activated in the user computers 15 
at a predetermined time, said first process 
sends the current configuration information of the 
object software to said second process in the vendor 
computer via the network to inquire about the latest 
configuration, 20 
receives the answer from said second process, 
updates the object software according to the update 

instruction information in the answer, and 
prepares for compiling and linking of programs if 
necessary to realize an automatic update of the object 25 
software; and 

when a user instructs the user computers to activate said 
first process, said first process 
sends the current configuration information of the 

object software to said second process in the vendor 30 

computer via the network to inquire about the latest 

configuration, 
receives the answer from said second process, 
updates the object software according to the update 

instruction information in the answer, and 35 
prepares for compiling and linking of programs if 

necessary. 

10. A software distribution/maintenance system for man- 
aging distribution of object software via a network by users 
who use one or more sets of the object software to be 40 
distributed, managed, and maintained and by software ven- 
dors who supply the users with the object software, com- 
prising: 

first process means for managing plural sets of the object 

software in each user computer; 
vendor software libraries in at least one vendor computer; 
second process means for providing services relating to 

said vendor software libraries in the at least one vendor 

computer; and 50 
a network for connecting each user computer and the at 

least one vendor computer, 

said first process means sending via the network an 
object software distribution/maintenance request 
message according to an instruction of the users or 55 
an instruction of a user-written program to said 
second process means of the at least one vendor 
computer containing desired object software, receiv- 
ing an answer message from the second process 
means, and distributing or maintaining the object 60 
software; and 

said second process means receiving the message from 
said first process means, referring to said vendor 
software libraries managed by the software vendors 
according to the message and settings made by the 65 
software vendors, generating an answer message in 
response to the object software distribution/ 
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maintenance request message, and sending the 
answer message to said first process means of a 
message sender. 

11. The software distribution/maintenance system accord- 
ing to claim 10, wherein 

when any object software managed by said first process 
means in the user computer abnormally terminates 
during its operation, said first process means detects 
and analyzes an abnormal condition, and then auto- 
matically sends a fault report to said second process 
means of the vendors over the network; and 

said second process means of the vendors receives the 
fault report and informs the vendors of the fault report. 

12. The software distribution/maintenance system accord- 
ing to claim 10 or claim 11, wherein when each version of 
the object software is provided for a number of the users by 
the vendors, a single computer user can be a user of a version 
of one piece of software and also a vendor of a version of 
another piece of software, and furthermore, a single com- 
puter can be provided with one or more first process means 
and one or more second process means. 

13. The software distribution/maintenance system accord- 
ing to claim 10, claim 11, or claim 12, wherein 

each user computer can be designed to store user man- 
agement data for each of the users or each user group, 
and the data can be set for each object software; and 

said first process means refers to the user management 
data to manage one or more sets of the object software. 

14. The software distribution/maintenance system accord- 
ing to claim 13, wherein said user management data includes 
at least one of user identification information of each user or 
each user group, software management information of each 
object software used by each user, software configuration 
information, and message process method specification 
information. 

15. The software distribution/maintenance system accord- 
ing to claim 14, wherein in specifying a method of process- 
ing a message according to the user management data, the 
users can specify a process method as a procedure for each 
function performed by said first process means. 

16. The software distribution/maintenance system accord- 
ing to claim 15, wherein 

in specifying a method of processing a message according 
to the user management data., a vendor confirmation 
procedure can be used so that the vendor can be 
conformed to protect user software. 

17. The software distribution/maintenance system accord- 
ing to claim 10, claim 11, or claim 12, wherein when said 
second process means of the at least one vendor computer 
offers services using said vendor software libraries, said 
second process means can refer to vendor management data 
stored for each vendor software library. 

18. The software distribution/maintenance system accord- 
ing to claim 17, wherein said vendor management data 
includes at least one of vendor identification information, 
software management information, software configuration 
information, message process method specification 
information, customer information, and fault history infor- 
mation. 

19. The software distribution/maintenance system accord- 
ing to claim 18, wherein when a message process method is 
specified using the vendor management data, the software 
vendors can specify a procedure for each function performed 
by said second process means. 

20. The software distribution/maintenance system accord- 
ing to claim 19, wherein a user confirmation procedure can 
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be selected when a message process method is specified 
using the vendor management data. 

21. The software distribution/maintenance systems 
according to claim 10 or claim 11, wherein 

Each of the users can simultaneously obtain and use a 5 
plurality of versions of each object software. 

22. A software distribution/maintenance method for man- 
aging distribution of object software via a network by users 
who use one or more sets of object software to be 
distributed, managed, and maintained and by software ven- 10 
dors who supply the users with the object software using, in 
user computers, the object software to be used by the users 
and a first process for managing one or more sets of object 
software; in each vendor computer, vendor software libraries 
and a second process for providing services relating to the 15 
vendor software libraries; and the network connecting each 
user computer to at least one vendor computer, comprising: 

activating by a sending user the first process through a 
command input by the sending user in one of the user 
computers or through a command from a user program; 20 

sending by the sending user from the first process in the 
one of the user computers via the network, an object 
software distribution/maintenance request message to 
the second process of the at least one vendor computer 
from which the object software is provided; 

receiving by the second process in the at least one vendor 
computer, from which the object software is provided, 
the object software distribution/maintenance request 
message from the first process; 30 

referring by the second process to the vendor software 
libraries managed by the software vendors according to 
the object software distribution/maintenance request 
message and settings made by the software vendors; 

generating an answer message in response to the object 35 
software distribution/maintenance request message; 

sending the answer message to the first process of the 
sending user; 

receiving by the first process in the one of the user 

computers of the sending user the answer message from 40 

the second process; and 
performing processes for distributing or maintaining the 

object software according to the answer message and 

settings made by the users. 

23. The software distribution maintenance method 45 
according to claim 22, 

wherein when executing object software managed by the 
first process in one of the user computers abnormally 
terminates during operation, the first process detects 5Q 
and analyzes an abnormal condition, and then sends a 
fault report message to a vendor of the executing object 
software via the network, and 

wherein the second process receives the fault report 
message via the network, and informs the vendor of the 55 
abnormal condition. 

24. The software distribution/maintenance method 
according to claim 22 or claim 23, wherein 

each user computer stores user management data for each 
of the users or each user group, identifying one or more 50 
sets of the object software; and 

said first process refers to the user management data to 
manage the one or more sets of the object software. 

25. The software distribution/maintenance method 
according to claim 24, wherein the user management data 65 
includes at least user identification information of at least 
one of the users, software management information of each 



object software used by each user in an object software 
group, software configuration information, and message 
process method specification information; and 

said first process refers to the user management data. 

26. The software distribution/maintenance method 
according to claim 25, wherein in referring to a method of 
processing a message according to the user management 
data, the sending user can specify and use a process method 
as a procedure for each function performed by the first 
process. 

27. The software distribution/maintenance method 
according to claim 26, wherein in referring to the method of 
processing the message according to the user management 
data, a user-defined vendor confirmation procedure is used 
so that the message received by the first process can be 
recognized as a correct message from a predetermined 
vender. 

28. The software distribution/maintenance method 
according to claim 25, wherein when the sending user 
activates the first process in one of the user computers by 
inputting a command, the first process 

obtains a user name, a command name, and an object 
software name to generate an interactive screen dis- 
playing messages according to the command, 

promotes generation of a message in response to the 
command from the sending user by referring to the user 
management data of the sending user and the object 
software or by invoking a user-defined process 
procedure, 

sends the message to the second process of the computer 

of the software vendors of the object software, and 
returns to a standby state after recording transmission of 



29. The software distribution/maintenance method 
according to claim 25 or claim 26, wherein if the first 
process is activated in the one of the user computers by an 
input command from a program defined by the sending user 
or through an abnormal termination of the object software 
managed by the first process, the first process 

obtains a user name, a command name, and an object 

software name, 
promotes generation of a message in response to a com- 
mand from the sending user by referring to the user 
management data of the sending user and the object 
software or by invoking a user-defined process 
procedure, 

sends the message to the second process in the at least one 

vendor computer, and 
returns to a standby state after recording transmission of 



30. The software distribution/maintenance method 
according to claim 25 or claim 26, wherein if the first 
process is activated in the one of the user computers by a 
message received from the network, then the first process 
obtains from a header of the answer message a destination 
user name identifying a specified user, a command 
name, and an object software name, 
uses the user management data for the specified user and 

the object software, 
then obtains a sender name from the header of the answer 
message, 

confirms that the message was sent by a correct vendor of 

the object software, 
also confirms that the first process is in an answer-wait 
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refers to the user management data or invokes the user- analyzes or stores message data or stores or installs the 
defined process procedure depending on the command software specified by the received message, 
in the answer message, returns, if the received message requires 
analyzes or stores message data or stores or installs the acknowledgment, an acknowledgment message with 
software specified by the answer message, returns, in 5 an acknowledgment or a process state to the second 
response to a specific message which requires process via the network, and 
acknowledgment, an acknowledgment or a process then returns to a standby state after recording a trans- 
state in an acknowledgment message to the second mission of the acknowledgment message, 
process via the network, and 32. The software distribution/maintenance method 
then returns to a standby sta'te after recording transmission 10 acc0I ff t0 claim 3 *> w °erein each time the first process is 
of the acknowledgment message. activated a new process is generated to allow plural pro- 
31. The software distribution/maintenance method cesses to be performed m paraUel on processes other than for 
according to any of claim 25 to claim 27, wherein said first a l^Lf 1 of ° b J ect s ° ftwar 1 e for a , sin ? le user ' 
process performs following processes depending on a cause 33 -. T s f ftw ^ e distribution/maintenance method 
activating the first process: 15 accordm g t0 cla ™ 22 or cla ™ 23, wherein when the second 
, „ . , process in the at least one vendor computer offers services 
when the sending user activates the first process m the usi the vendof software vendor ma ent 
sending user computers by inputting a command, the daUj stored for each vendor ^ referred tQ 

first process 34. The software distribution/maintenance method 

obtains a user name, a command name, and an object 2Q according t0 claim 33> wherein when the second ss 

software name to generate an interactive screen refers t0 the vendor management data> reference £ made 

displaying message according to the input command, correS ponding to the vendor software library to at least 

promotes generation of a first message in response to vendor identification information, software management 

the command from the sending user by referring to information, software configuration information, message 

the user management data of the sending user and the 25 process method specificat i on in fo rma tion, customer 

object software or by invoking a user-defined pro- information, update history information, and fault history 

cess procedure, information, 

sends the message to the second process of the at least 35 . The software distribution/maintenance method 

one vendor computer storing the object software, and according t0 claim 34, wherein when a message process 

returns to a standby state after recording transmission 3Q method ^ referred t0 min the vendor man ag em ent data, a 

of the object software distribution/maintenance procedure each function performed by the second process is 

request message; invoked, 

if the first process is activated in the one of the user 36. The software distribution/maintenance method 

computers by an input command from a program according to claim 35, wherein when the message process 

defined by the sending user or through an abnormal 35 method is referred to using the vendor management data, a 

termination of the object software managed by the first user confirmation procedure can be invoked to confirm an 

process, the first process identification of the sending user of the object software 

obtains a user name, a command name, and an object distribution/maintenance request message, determine a 

software name, qualification of the sending user, and return an appropriate 

promotes in response to an activated command genera- 40 answer to the sending user. 

tion of a second message in response to a command 37. The software distribution/maintenance method 

from the sending user by referring to the user man- according to claim 36, wherein in the user confirmation 

agement data of the sending user and the object procedure as a part of the vendor management data, the 

software or by invoking a user-defined process qualification of the sending user can be determined based on 

procedure, 45 commercial relations including at least one of contracts 

sends the second message to the second process of the relating to the object software, payments relating to the 

at least one vendor computer storing the object object software, and payments relating to new services for 

software, and the object software, 

returns to a standby state after recording transmission 38. The software distribution/maintenance method 

of the second message; and 50 according to claim 36, wherein in the user confirmation 

if the first process is activated in the one of the user procedure depending on the vendor management data, the 

computers by a received message from the network, object software is provided and distributed only to qualified 

then the first process users by referring to identification information including at 

obtains from a header of the received message a least one of organizations, titles, and personal names thereof, 

destination user name, a command name, and an 55 39. The software distribution/maintenance method 

object software name, according to claim 36, wherein 

uses the user management data for a specified user and in the user confirmation procedure as a part of the vendor 

the object software, management data, the user can be identified by a 

then obtains a sender name from the header of the password. 

received message, 60 40. The software distribution/maintenance method 

confirms that the received message was sent by a according to claim 22 or claim 23, wherein the one of the 

correct vendor of the object software, user computers and the at least one vendor computer are 

also confirms that the first process is in an answer-wait connected to the network only when sending and receiving 

state, messages between each other or a relaying device in the 

refers to the user management data or invokes the 65 network, 

user-defined process procedure depending on the 41. The software distribution/maintenance method 

command name in the received message, according to claim 22, or claim 23 wherein the object 
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software distribution/maintenance request message trans- 
mitted via the network has a destination and a source of the 
message, and a title column specifying a name of a software 
distribution/maintenance system, a name of a software 
distribution/maintenance process type, and a name of the 5 
object software. 

42. The software distribution/maintenance method 
according to claim 22, claim 23, or any of claims 33 to 39, 
wherein the second process in the at least one vendor 
computer is normally in a standby state, and upon being 10 
activated by receiving the object software distribution/ 
maintenance request message from the first process via the 
network 

obtains a command name and an object software name of 
specified software from a header of the object software 15 
distribution/maintenance request message, 

assigns processes to be performed, 

obtains a name of the sending user and user identification 
information from the object software distribution/ 
maintenance request message, 20 

compares the name of the sending user with vendor 
management data to determine a user access qualifica- 
tion relating to the command name, 

analyzes the object software distribution/ maintenance 25 
request message if the sending user qualifies, 

provides summary information of the specified software, 

provides new services for the specified software, 

supplies updated software and instructions to correctly 
update the specified software, retrieves information of 30 
other messages, 

generates the answer message, 

records a summary of the answer message to the sending 

sends the answer message to the first process of the 35 

sending user via the network, and 
returns to the standby state. 

43. The software distribution/maintenance method 
according to claim 42, wherein each time the second process 40 
is activated, a new process is generated to allow a plurality 

of processes to be concurrently performed on processes 
other than for a single set of object software for a single user. 

44. The software distribution/maintenance method 
according to claim 22, or claim 23 wherein when the users 45 
obtain summary information of the object software not yet 
used by the users, following processes are performed: 

in the one of the user computers, 
the sending user 

enters a summary inquiry command, 50 
activates the first process in the one of the user 
computers, 

sets a name of specified object software, a name of 
a specified vendor, a network address of the speci- 
fied vendor, and an answer information storage 55 
directory, and 
generates a summary information inquiry message; 
the first process sends the summary information inquiry 
message to the second process of the specified ven- 
dor; 60 
in the at least one vendor computer, 

the second process is activated when the summary 
information inquiry message is received via the 
network; 

the second process 65 
refers to vendor management data about the specified 
object software cited by the summary information 
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inquiry message to confirm an identification of the 
sending user and determine access qualification of 
the sending user; 
invokes, if the sending user is qualified, a vendor- 
defined procedure to provide summary informa- 
tion in a summary information message; and 
sends the summary information message to the first 
process of the sending user via the network. 
45. The software distribution/maintenance method 
according to claim 22 or claim 23, wherein when the users 
newly obtain the object software not yet used by the users, 
following processes are performed: 
in the one of the user computers, 
the sending user 
enters a new installation command, 
activates the first process in the one of the user 
computers, 

sets user identification information, software infor- 
mation of specified object software, vendor iden- 
tification information, and user installation pro- 
cess information, and 
generates a new installation request message; and 
the first process sends the new installation request 
message to the second process managing the speci- 
fied object software; 
in the at least one vendor computer, 

the second process is activated when the new installa- 
tion request message is received via the network, 
the second process 

refers to vendor management data about the specified 
object software to confirm identification of the 
sending user and determine access qualification of 
the sending user; 
invokes, if the sending user is qualified, a vendor- 
defined procedure for new installation to deter- 
mine a version to be provided, 
obtains a set of modules of the version to be 
provided, 

organizes instruction information of the new instal- 
lation in the one of the user computers, and 
generates a new installation message as the answer 
message, 

sends the new installation message as the answer 

message to the first process of the sending user via 

the network; 
in the user computer, 

the first process is activated when the new installation 

message is received via the network, 
the first process 
obtains a name of a destination user and a name of 

specified object software from a header of the new 

installation message, 
refers to corresponding user management data, 
confirms that the first process is currently in a new 

installation standby state and that a correct vendor 

sent the new installation message, 
invokes a user-defined new installation process 

procedure, 

refers to installation information in the new instal- 
lation message, 

stores the specified object software to be newly 
installed in the one of the user computers, 

installs the set of modules if the new installation is 
acceptable, 

records the new installation message and a process 

result, and 
returns to the standby state. 
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46. The software distribution/maintenance method 
according to claim 22, or claim 23, wherein when the users 
add or switch to a new service of the object software already 
used by the users, following processes are performed: 

in the one of the user computers, s 
the sending user 
enters a new service request command, 
activates the first process in the one of the user 
computers, 

sets user identification information, software infor- 10 
mation of specified object software, vendor iden- 
tification information, and user installation pro- 
cess information, and 
generates a new service request message; 
the first process sends the new service request message 15 
to the second process of the at least one vendor 
computer; 
in the at least one vendor computer, 

the second process is activated when the new service 

request message is received via the network; 20 
the second process 
refers to vendor management data about the specified 
object software cited by the new service request to 
confirm identification of the sending user and 
determine access qualification of the sending 2 5 

invokes, if the sending user is qualified, a vendor- 
defined procedure for a supply of the new service 
to determine a version to be provided, 

obtains a set of modules of the version to be 30 
provided, 

organizes instruction information of installation in 

the one of the user computers, 
specifies a process to be performed on an old service, 
generates a new installation message as an answer, 35 

and 

sends the new installation message as the answer to 
the first process of the sending user via the net- 
work; 

in the user computer, 40 
the first process is activated when the new installation 

message is received via the network; 
the first process 

obtains a name of a destination user and the name of 
the specified object software from a header of the 45 
new installation message, 

refers to corresponding user management data, 

confirms that the third process is currently in a new 
installation standby state and a correct vendor sent 
the new installation message, 50 

invokes a user-defined process procedure, 

refers to installation information in the new instal- 
lation message, 

stores specified software supplied as the new service 
in the one of the user computers, 55 

stores the new service of the specified software if the 
new service is acceptable, 

records the new installation message and a process 
result, and 

returns to the standby state. 60 

47. The software distribution/maintenance method 
according to claim 22 or claim 23, wherein when the users 
inquire of the vendors about an update state of installed 
object software already used by the users and request 
updated object software, following processes are performed: 65 

in the one of the user computers, 
the sending user 



5 of the user 



106 

enters an update inquiry command, 
activates the first process in the 01 
computers, 

sets user identification information, software infor- 
mation of the installed object software, vendor 
identification information, software management 
information, and user installation process 
information, and 
generates an update inquiry message; 
the first process sends the update inquiry message to the 
second process of a specified vendor identified by the 
vendor identification information; 
in the at least one vendor computer, 
the second process is activated when the update inquiry 

message is received via the network; 
the second process 

refers to vendor management data about the installed 
object software cited by the update inquiry mes- 
sage to confirm identification of the sending user 
and determine access qualification of the sending 
user, 

invokes, if the sending user is qualified, a vendor- 
defined update inquiry answering procedure to 
determine a version type to be supplied and a 
latest version and compares the latest version with 
a current version of the sending user; 
if the current version of the sending user matches the 

latest version, then the second process 

generates a non-update message, and 

sends the non-update message to the first process of 
the sending user; 
if the undated object software with the version type of 

the current version of the installed object software 

exists, then the second process 

generates module delete/add instruction information 
about modules to be added in an update instruction 
message as an answer, and 

sends the answer to the first process of the sending 
user via the network; 
if the current version should be switched to a newly 

served version of the installed object software, then 

the second process 

generates the non-update message and an informa- 
tion message about the newly served version, and 
sends the non-update message and the information 
message to the first process of the sending user via 
the network; 
n the one of the user computers, 
the first process is activated when a received message 
is the update instruction message or the non-update 
message received via the network; 
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obtains a name of a destination user and a name of 

specified object software from a header of the 

received message, 
refers to corresponding user management data, and 
confirms that the first process is currently in a 

standby state after inquiry and that a correct 

vendor sent the received message; 
if the non-update message is received, the first process 
records the non-update message and returns to the 
standby state; 
if the update instruction message is received, the first 
process 

invokes a user-defined update reception process 
procedure, 

refers to the module delete/add instruction informa- 
tion in the received message, 
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stores in the one of the user computers the specified 
object software specified by the update instruction 



,911 



installs the specified object software if the specified 

object software is acceptable, and 
records the received message and a process result, 
and returns to the standby state. 
48. The software distribution/maintenance method 
according to claim 22 or claim 23, wherein when the users 
inquire about an update state of installed object software 
already used by the users and request updated object 
software, following processes are performed: 
in the one of the user computers, 
the first process 
is activated according to an update inquiry command 

instruction of a user program, 1 
invokes a user-defined automatically-editing update 

inquiry procedure, 
refers to user management data, and 
generates an update inquiry message; 
the first process sends the update inquiry message to the 2 
second process of a specified vendor of the installed 
object software; 
in the at least one vendor computer, 

the second process is activated when the update inquiry 

message is received via the network; 2 
the second process 
refers to vendor management data about the installed 
object software cited by the update inquiry mes- 
sage to confirm identification of the sending user 
and determine access qualification of the sending 3 
user, and 

invokes, if the sending user is qualified, a vendor- 
defined update inquiry answering procedure to 
determine a version type to be supplied and a 
latest version and compare the latest version with 
the current version of the sending user; 3 
if the current version of the sending user matches the 

latest version, then the second process 

generates a non-update message, and 

sends the non-update message to the first process of 
the sending user; 4 
if the installed object software of the version type of the 

current version of the sending user has been updated, 

then the second process 

generates module delete/add instruction information 
and information about modules to be added in an 4 
update instruction message as an answer, and 

sends the updated instruction message to the first 
process of the sending user via the network; 
if the current version should be switched to a newly 

served version of the installed object software, then 5 

the second process 

generates a non-update message and an information 

message about the newly served version, and 
sends the non-update message to the first process of 
the sending user via the network; 5 
in the user computer, 

the first process is activated when the update instruction 
message or the non-update message is received from 
the second process via the network; 
the first process 6 
obtains a name of a destination user and a name of 
the object software from a header of a received 
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if the non-update message is received, the first process 
records the received message and returns to the 
standby state; 

if the update instruction message is received, the first 
process 

invokes a user-defined update reception process 
procedure, 

refers to the module delete/add instruction informa- 
tion in the received message, 

stores in the one of the user computers the modules 
to be added specified by the update instruction 



refers to corresponding user management data, and 
confirms that the first process is currently in a i 

standby state after inquiry and that a correct 

vendor sent the received message; 



installs the modules to be added if acceptable, 
records the received message and a process result, 
and 

returns to the standby state. 

49. The software distribution/maintenance method 
according to any of claim 45 to claim 48, wherein if the first 
process receives a message from a sending vendor, and 
stores or installs in the one of the user computers new 
software, newly served software, or updated software 
received from the sending vendor, then the first process 
monitors a result of processes and sends to the second 
process via the network a process result confirmation mes- 
sage informing whether the processes have terminated nor- 
mally or abnormally. 

50. A software distribution/maintenance system having a 
plurality of user computers and a vendor computer to 
manage and automatically update object software provided 
for the plurality of user computers from the vendor 
computer, comprising: 

network means for connecting the user computers to the 
vendor computer; and 

process means in each of the user computers, for sending 
current configuration information of the object soft- 
ware stored in the user computers to the vendor com- 
puter via said network means to inquire about a latest 
configuration, for receiving an answer from the vendor 
computer, and for updating the object software stored 
in the user computers according to an instruction in a 
received answer. 

51. The software distribution/maintenance system accord- 
ing to the claim 50, wherein said process means in the user 
computers automatically informs via said network means the 
vendor computer of an abnormal termination and state if an 
operation of the object software abnormally terminates in 
the user computers. 

52. The software distribution/maintenance system accord- 
ing to claim 51, wherein said process means automatically 
informs the vendor computer of the abnormal termination, 
an instruction causing the abnormal termination, a reason for 
the abnormal termination, a series of instructions which 
invoked the instruction causing the abnormal termination, 
and an environment of software and hardware used when the 
abnormal termination is detected. 

53. The software distribution/maintenance system accord- 
ing to claim 51, wherein said process means automatically 
informs via said network means the vendor computer of the 
abnormal termination by general-purpose electronic mail. 

54. A software distribution/maintenance system having a 
plurality of user computers and a vendor computer to 
manage and automatically update object software provided 
for the plurality of user computers from the vendor 
computer, comprising: 

network means for connecting the user computers to the 

vendor computers; and 
process means in the vendor computer for receiving an 

inquiry from the user computer, for generating update 
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instruction information for the object software to match 
a configuration of the object software in the user 
computer with the configuration of an updated version 
in an object software library stored in the vendor 
computer, and for returning via said network means to 5 
the user computer the update instruction information 
and the updated version of the object software. 

55. A software distribution/maintenance method for man- 
aging and automatically updating a set of object software 
stored in user computers from a vendor computer via a 10 
network, comprising: 

sending by a process in the user computers current 
configuration information of the object software to the 
vendor computer via the network to inquire about a 
latest configuration; 15 

receiving by the process an answer with update instruc- 
tion information from the vendor computer; and 

updating the object software according to the update 
instruction information about the object software to 
match a configuration of the object software with the 20 
latest configuration stored in an object software library 
in the vendor computer, including preparing for com- 
piling and linking of programs if necessary. 

56. The software distribution/maintenance method 
according to claim 55, wherein when the object software is 25 
activated in the user computers, the process in the user 
computers 

immediately sends the current configuration information 
of the object software to the vendor computer via the 3Q 
network to inquire about the latest configuration, 
receives the answer from the vendor computer, updates 
the object software according to the update instruction 



inforn 



□ the a 



prepares for compiling and linking of programs if neces- 35 
sary. 

57. The software distribution/maintenance method 
according to claim 55, wherein when the process is activated 
in the user computers at a predetermined time, the process 

sends the current configuration information of the object 40 

software to the vendor computer via the network to 

inquire about the latest configuration, 
receives the answer from the vendor computer, 
updates the object software according to the update 

instruction information in the answer, and 45 
prepares for the compiling and linking of programs if 

necessary to realize an automatic update of the object 

software. 

58. The software distribution/maintenance method JQ 
according to claim 55, wherein when a user instructs the user 
computers to activate the process, the process 

sends the current configuration information of the object 
software to the vendor computer via the network to 
inquire about the latest configuration, 55 

receives the answer from the vendor computer, updates 
the object software according to the update instruction 
information in the answer, and 

prepares for the compiling and linking of programs if 



according to claim 55, wherein following processes are 
interchangeably performed: 

when the object software is activated in the user 
computers, the process 6 
immediately sends the current configuration informa- 
tion of the object software to the vendor computer 
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via the network to inquire about the latest 

configuration, 
receives the answer from the vendor computer, 
updates the object software according to the update 

instruction information in the answer, and 
prepares for compiling and linking of programs if 

necessary; 

when the process is activated in the user computers at a 
predetermined time, the process 
sends the current configuration information of the 

object software to the vendor computer via the 

network to inquire about the latest configuration, 
receives the answer from the vendor computer, 
updates the object software according to the update 

instruction information in the answer, and 
prepares for the compiling and linking of programs if 

necessary to realize an automatic update of the object 

software; and 

when a user instructs the user computers to activate the 
process, the process 

sends the current configuration information of the 
object software to the vendor computer via the 
network to inquire about the latest configuration, 

receives the answer from the vendor computer, 

updates the object software according to the update 
instruction information in the answer, and 

prepares for the compiling and linking of programs if 
necessary. 

60. A software distribution/maintenance method for man- 
aging and automatically updating a set of object software 
stored in user computers from a vendor computer via a 
network, comprising: 

receiving by a process stored in the vendor computer an 
inquiry from an inquiring user computer about current 
configuration information of the object software, in the 
user computer; 

generating update instruction information about the object 
software to update the current configuration of the 
object software in the user computer with a latest 
configuration version in an object software library in 
the vendor computer; and 

returning the update instruction information and an 
updated version of the object software to the inquiring 
user computer via the network. 

61. A software distribution/maintenance system for man- 
aging distribution of object software via a network accessed 
by users of user computers who use sets of the object 
software distributed, managed, and maintained by software 
vendors who supply the users with the object software from 
at least one vendor computer, comprising: 

a network for connecting each user computer and the at 
least one vendor computer; and 

process means in each user computer for executing the 
object software to be used by the users, for managing 
the sets of object software in each user computer, for 
sending via the network an object software distribution/ 
maintenance request message according to an instruc- 
tion of the users or an instruction of a user-written 
program to the at least one vendor computer which has 
a software library containing the object software, for 
receiving an answer message from the at least one 
vendor computer, and for distributing or maintaining 
the object software. 

62. The software distribution/maintenance system accord- 
ing to claim 61, wherein when any object software managed 
by said process means in each user computer abnormally 



Ill 

;s during operation, said process means detects and 
analyzes an abnormal condition, and then automatically 
sends a fault report to the at least one vendor computer via 
said network. 

63. The software distribution/maintenance system accord- 5 
ing to claim 61, wherein 

each user computer can store user management data for 
each of the users or each user group, and for each set 
of the object software; and 

said process means refers to the user management data to 10 
manage one or more sets of the object software. 

64. The software distribution/maintenance system accord- 
ing to claim 63, wherein said user management data includes 
user identification information of each user or each user 
group, software management information of each set of the 15 
object software used by each user, software configuration 
information, and message process method specification 
information. 

65. The software distribution/maintenance system accord- 
ing to claim 64, wherein in specifying a method of process- 20 
ing a message according to the user management data, the 
users can specify a process method as a procedure for each 
function performed by said process means. 

66. The software distribution/maintenance system accord- 
ing to claim 65, wherein in specifying a method of process- 25 
ing a message according to the user management data, a 
vendor confirmation procedure can be used so that the 
vendor can be confirmed to protect user software. 

67. A software distribution/maintenance system for man- 
aging distribution of object software via a communications 30 
network accessed by users of user computers use sets of the 
object software distributed, managed, and maintained by 
software vendors who supply the users with the object 
software from at least one vendor computer, comprising: 

network means for connecting each user computer and the 

at least one vendor computer; 
vendor software libraries; and 

process means for providing services relating to said 
vendor software libraries, for receiving an object soft- 40 
ware distribution/maintenance request message from 
an inquiring user computer via said network means, for 
referring to one of said vendor software libraries, 
managed by a vendors according to contents of the 
object software distribution/maintenance request mes- 45 
sage and settings of the vendor, for generating an 
answer message in response to the object software 
distribution/maintenance request message, and for 
sending the answer message to the inquiring user 
computer via said network means. 50 

68. The software distribution/maintenance system accord- 
ing to claim 67, wherein when any object software abnor- 
mally terminates during operation in one of the user 
computers, said process means sends a fault report received 
from the one of the user computers via said network means 55 
to the vendor of the object software which abnormally 
terminated. 

69. The software distribution/maintenance system accord- 
ing to claim 67, wherein when said process means of the at 
least one vendor computer offers services using said vendor go 
software libraries, said process means refers to vendor 
management data stored for each vendor software library. 

70. The software distribution/maintenance system accord- 
ing to claim 69, wherein 

said vendor management data can be designed to com- 65 
prise vendor identification information, software man- 
agement information, software configuration 
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information, message process method specification 
information, customer information, and fault history 
information. 

71. The software distribution/maintenance system accord- 
ing to claim 70, wherein when a message process method is 
specified using the vendor management data, the software 
vendors can specify the message process method as a 
procedure for each function performed by said process 
means. 

72. The software distribution/maintenance system accord- 
ing to claim 70, wherein 

a user confirmation procedure can be selected when a 
message process method is specified using the vendor 
management data. 

73. A software distribution/maintenance method for man- 
aging distribution of object software via a network accessed 
by users of user computers who use sets of the object 
software distributed, managed, and maintained by software 
vendors who supply the users with the object software from 
at least one vendor computer using, in each user computer, 
the object software to be used by the users and a process 
managing the sets of the object software, and the network 
connecting each user computer and the at least one vendor 
computer, comprising: 

activating by the users the process through a command 
input by the users or through a command from a 
user-written program; 

sending by the process via the network an object software 
distribution/maintenance request message to the at least 
one vendor computer from which the object software is 
provided; 

receiving by the process the answer message from the at 
least one vendor computer; and 

performing processes for at least one of distributing and 
maintaining the object software according to the 
answer message and settings made by the users. 

74. A software distribution/maintenance method for man- 
aging distribution of object software via a network accessed 
by users of user computers who use sets of the object 
software distributed, managed, and maintained by software 
vendors who supply the users with the object software using, 
in each vendor computer, vendor software libraries and a 
vendor process providing services relating to the vendor 
software libraries, the network connecting each user com- 
puter and each vendor computer, said software distribution/ 
maintenance method comprising: 

receiving by the vendor process an object software 
distribution/maintenance request message from one of 
the user computers via the network; 

referring by the vendor process to the vendor software 
libraries managed by one of the vendors according to 
the object software distribution/maintenance request 
message and settings made by the one of the vendors; 

generating an answer message in response to the object 
software distribution/maintenance request message; 

sending the answer message to the one of the user 
computers which issued the object software 
distribution/maintenance request message. 

75. A software distribution and maintenance system using 
a network in which a plurality of users using a number of 
types of object software to be distributed, managed, and 
maintained, and a plurality of software vendors supplying 
the object software manage the distribution and maintenance 
of the object software over a computer network, comprising: 

one or more first process means CP installed in each of 
user computers, that manage a plurality of object soft- 
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ware groups to be used by one or more users individu- 
ally for every object software and for every user; 
one or more second process means installed in one or 
more software vendor computers, that each providing 
services to a Plurality of vendor software libraries for 
each of the software libraries; and 
a network that connects the first process means installed 
in the user computer to the second process means, 
based on standardized communications protocols, 
said first process means having a capability to perform 
distribution or maintenance of the object software by 
sending a message a request of distribution or main- 
tenance of the object software for one piece of object 
software over the network, according to instructions 
given by one or more of the users or a user defined 
program, receiving an answer message from the 
second process means SP, and processing based on 
contents of the answer message and settings made by 
the users, and 
said second process means having a capability to 
receive the message from each first process means to 
reference one or more of the software libraries 
managed by one or more of the vendors depending 
on the contents of the message and settings made by 
the vendors for the object software specified with the 
message, to generate the answer message to answer 
the request of distribution or maintenance of the 
object software, and to send the answer message to 
said first process means that generated the message. 

76. The software distribution and maintenance system 
using a network according to claim 75, used by the users 
taking advantage of one or more pieces of the object 
software included in the object software groups, and the 
vendors supplying one or more pieces of the object software 
in the object software groups, wherein one or more com- 
puters each comprise both said one or more first process 
programs and said one or more second process means. 

77. The software distribution and maintenance system 
using a network according to claim 75, wherein the message, 
sent and received over said network between said first 
process means installed in one of the user computers, and 
said second process means installed in one of the vendor 
computers, consists of a header part of the message, an 
attribute part as fixed data, an instructing part as a specific 
request and instruction data, and a module part as corre- 
sponding software. 

78. The software distribution and maintenance system 
using a network according to claim 75, wherein the attribute 
part forming a part of the message is configured as hierar- 
chical structure data of a pair of a keyword and a value, 
facilitates referencing and updating management data for 
user set for every object software and for every user, and 
management data for vendor set for every object software 
library and for every vendor. 

79. User computers used in a software distribution and 
maintenance system using a network in which a plurality of 
users using a plurality of types of object software to be 
distributed, managed, and maintained, and a plurality of 
software vendors supplying the object software manage the 
distribution and maintenance of the object software over 
said network, comprising: 

one or more process means that manage a plurality of 
object software groups to be used by the users indi- 
vidually for every object software and for every user 
using the object software; and 

storage means for storing management data for user set 
for every user for every object software and user 
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process procedures which are process procedures for 
said process means to distribute and maintain the object 
software, set for every object software and for every 
user, said process means calling said user process 

5 procedures to reference the management data for user, 
send a message to request distribution and maintenance 
of the object software to the vendor of the object 
software over said network according to standardized 
protocols in the system, and perform distribution and 

10 maintenance of the target software. 

80. The user computers in the software distribution and 
maintenance system using a network according to claim 79, 
wherein the management data for user includes user iden- 
tification information corresponding to each user, vendor 

15 identification information corresponding to each object soft- 
ware vendor, software identification information corre- 
sponding to each object software, and environment infor- 

81. The user computers in the software distribution and 
20 maintenance system using a network according to claim 79, 

wherein each user process procedure comprises: 

message-editing procedures that edit a message to request 
distribution and maintenance sent from said user pro- 
cess procedure to the vendor of the object software; 
25 a vendor verification procedure that verifies a vendor of 
the object software; and 
reception process procedures that process an answer mes- 
sage from the vendor of the object software. 
30 82. The user computers in the software distribution and 
maintenance system using a network according to claim 79, 
each comprises said management data for user, said user 
process procedures, and said first process means for each of 
the plurality of versions of the object software so that every 
35 user can utilize the plurality of versions. 

83. The user computers in the software distribution and 
maintenance system using a network according to claim 79, 
each comprises data for specifying a plurality of versions for 
said management data for user, and both said user process 

40 procedures and said first process means for the plurality of 
versions so that every user can utilize a plurality of versions 
of an identical piece of the object software at the same time. 

84. A vendor computer in a software distribution and 
maintenance system using a network in which a plurality of 

45 users using a plurality of types of object software to be 
distributed, managed, and maintained, and a plurality of 
software vendors supplying the object software manage the 
object software distribution for distributing the object soft- 
ware over said network, comprising: 
50 at least one process means for providing services of each 
of the software libraries and each of the vendor soft- 
ware libraries; and 
storage means for storing management data for vendor set 
for every vendor and for every software library, and 
55 vendor process procedures which are process proce- 
dures for said process means to distribute and maintain 
the object software on the user computers, set for every 
vendor and for every software library, said process 
means performing a corresponding process for a mes- 
60 sage of the object software from the user, set for every 
vendor and for every object software library. 

85. The vendor computer in the software distribution and 
maintenance system using a network according to claim 84, 
wherein said management data for each vendor includes user 

65 identification information concerning all the users of the 
object software, vendor identification information concern- 
ing the vendor of the object software library, software 
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information concerning the object software library, and 
environment information. 

86. The vendor computer in the software distribution and 
maintenance system using a network according to claim 84, 
wherein said vendor process procedures include a user 5 
qualification verification procedure for the object software, 
an unqualified user process procedure, reception and answer 
process procedures for analyzing a message received from 
the user, and generating an answer message. 

87. The vendor computer in the software distribution and 10 
maintenance system using a network according to claim 84, 
wherein said object software library includes a plurality of 
versions of the object software, and said process means 
corresponding to the object software library gives services to 
said object software library using management data for 15 
vendor and vendor process procedures that correspond to a 
plurality of versions. 

88. A software distribution and maintenance method in 
which a plurality of users using a plurality of types of object 
software to be distributed, managed, and maintained, and a 20 
plurality of software vendors supplying the object software, 
manage distribution and maintenance of the object software, 
said method utilizing at least one first process in each of a 
plurality of user computers, that manage object software 
groups to be used by the users individually for every object 25 
software and for every user using the object software, at 
least one second process in vendor computers, that provide 
services to vendor software libraries for each of the vendor 
software libraries, and a network that connects the user 
computers to the vendor computers standardized communi- 30 
cation protocols, said method comprising: 

invoking a first process with a command entered by one 
of the users on one of the user computers or with a 
command invoked from a user-defined program; 

sending a request message from the first process to 35 
request distribution or maintenance of at least one piece 
of the object software to a second process managing at 
least one of the vendor software libraries of the object 
software; 

receiving the request message by the second process in 40 
one of the vendor computers; 

generating an answer message to answer the request 
message by referencing at least one of the vendor 
software libraries managed by at least one of the 4J 
software vendors for the at least one piece of the object 
software specified by the request message; 

returning the answer message to the first process; 

receiving the answer message by the first process; and 

processing the answer message depending on contents of 50 
the answer message and settings made by the one of the 
users for the distribution or maintenance of the at least 
one piece of the object software. 

89. The software distribution and maintenance method 
using a network according to claim 88, wherein the first 55 
process means installed in the user computers, which is 
invoked with a command entered by the user on the user 
computers, or a command in a user-defined program, calls a 
message-editing procedure which is one of user process 
procedures for distributing and maintaining the object 60 
software, edits a message to request distribution and main- 
tenance based on the standardized protocols within the 
system while referencing the management data for user set 
for message and generating an answer message, references 
the object software library while referencing and updating 65 
said management data for vendor, and generates an answer 
message for distribution and maintenance of the object 
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software in response to the received message to request 
distribution and maintenance, and returns the answer mes- 
sage to the first process means. 

90. The software distribution and maintenance method 
using a network according to claim 88, wherein the first 
process installed in the user computers, 

receives the answer message returned from the second 
process in response to the request message sent by the 
first process to request distribution or maintenance of 
the object software, 

verifies that the answer message is returned from a legal 
vendor, 

calls a reception process procedure which is one of user 
process procedures set for the one of the users and for 
the object software, 

performs distribution and maintenance of the object soft- 
ware according to contents of the answer message, and 

prepares for execution of the object software according to 
a determination made by the first process while refer- 
encing and updating management data for user set for 
the one of the users and for the object software. 

91. The software distribution and maintenance method 
using a network according to claim 88, wherein the first 
process installed in the one of the user computers 

receives the answer message returned by the second 
process in response to the request message sent by the 
first process to request distribution and maintenance of 
the object software, 

performs distribution and maintenance of the object soft- 
ware according to the answer message, and 

then automatically returns a response message to the 
second process indicating whether the distribution and 
maintenance was properly executed on the one of the 
user computers. 

92. The software distribution and maintenance method 
using a network according to claim 88, wherein said second 
process installed in the vendor computers 

receives the request message from the first process to 
request distribution and maintenance of the object 
software belonging to the vendor software libraries 
managed by the second process, 

verifies that the request message to request distribution 
and maintenance is sent from a legal user by referenc- 
ing user identification information included in vendor 
management data set for the software vendors and for 
the vendor software libraries, 

calls a reception/answer process procedure for analyzing 
the request message and generating the answer 
message, 

references the at least one of the vendor software libraries 
while referencing and updating the vendor manage- 
ment data, 

generates the answer message for distribution and main- 
tenance of the object software in response to the request 
message to request distribution and maintenance, and 

returns the answer message to the first process. 

93. The software distribution and maintenance method 
using a network according to claim 88, wherein a message, 
which is sent and received over the network between the first 
process means (CP) installed in one of the user computers 
and the second process means installed in one of the vendor 
computers, consists of a header part of the message, an 
attribute part as fixed data, an instructing part, a specific 
request and instruction data, an instructing part as instruc- 
tion data, and a module part as corresponding software. 
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94. A method for purchasing new software in a software 
distribution and maintenance system using a network, in 
which a plurality of users using a plurality of types of object 
software to be distributed, managed, and maintained, and a 
number of software vendors supplying the object software 
manage the distribution and maintenance of the object 
software over a network, comprising: 

one of the users sending a message to request summary 
information of the object software from first process 
means in the user computers to second process means 
over said network by use of any of the first process 
means which simply has the capability to request 
summary information and of receiving an answer mes- 
sage to the request of summary information; 
the second process means providing basic components of 
the first process means and user process procedures 
sufficient for a new purchase of the object software as 
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part of the answer message in response to the summary 

inquiry to the user computers over the network; 
the user sending a message to request a new purchase to 

the second process means over the network using the 

basic components of the first process means and the 

user process procedures; 
the second process means providing the whole set of said 

first process means and user process procedures appro- 
10 priate for the distribution and maintenance of the object 

software to the user's first process means over the 

network; 

the user computers thereafter distributing and maintaining 
the object software using the first process means and 
15 the user process procedures. 
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[57] ABSTRACT 

A system for updating an agent used in a backup software 
program. The backup software program operates on a net- 
work having, for example, a server and a number of work- 
stations. A backup engine executes on the server. An agent 
executes on each of the workstations to be backed up. The 
backup engine transmits an updated agent to each 
workstation, transmits an executable regeneration module to 
each workstation and transmits an execute command to the 
agent at each workstation. The agent at each workstation 
stores the updated agent and the executable regeneration 
module and causes the execution of the executable regen- 
eration module. The executable regeration module deletes or 
renames the agent, and also renames the updated agent to the 
name of the agent and thereafter enables operation of the 
updated agent as the agent. 

14 Claims, 4 Drawing Sheets 
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REGENERATION AGENT FOR BACK-UP 
SOFTWARE 

FIELD OF INVENTION 

The present invention is directed to agent modules used in 
back-up software systems, and more particularly, to a system 
and method for updating agent modules on a remote work- 
station. 

COPYRIGHT NOTICE 

A portion of the disclosure of this patent document 
contains material that is subject to copyright protection. The 
copyright owner has no objection to the facsimile reproduc- 
tion by anyone of the patent document or patent disclosure 
as it appears in the Patent and Trademark Office patent file 
or records, but otherwise reserves all copyright rights what- 
soever. 

BACKGROUND OF THE INVENTION 

Modern computer networks are often organized according 
to a client/server architecture. A client/server architecture is 
an arrangement used on local area networks ("LANs") that 
treats both the server and the individual workstations as 
intelligent, programmable devices. Typically, a LAN com- 
prises a number of "front-end" client computers and a 
"back-end" server. The client component typically a per- 
sonal computer, offers the user its full range of power and 
features for running programs. Usually, the client computer 
(called herein a workstation) has its own processing capa- 
bility and a hard disk drive or other local storage device. The 
server, which can be a personal computer, a minicomputer or 
a mainframe, enhances the client component by providing 
services such as data management, information sharing and 
security. Servers provide services to workstations including, 
for example, back-up services. 

Often, a user of the LAN (typically a network manager) 
wishes to back-up data stored on the hard drive(s) of some 
or all of the computers on the LAN. including the worksta- 
tions. In the back-up process, the files stored on workstations 
and servers of the LAN are down-loaded onto a central 
storage device, such as a tape on a tape drive. Thus, for 
example, if a file is damaged on a workstation, the network 
manager can retrieve the back-up copy of the lost data from 
the central back-up storage device. 

A typical back-up program has a number of components. 
A backup engine, running centrally on the server, can control 
the writing of data to the backup storage device (for a 
backup job), control the reading of data from the backup 
storage device (for a restore job), manage a task queue of 
jobs, and control communications with the client computers. 
An administrator console, which typically runs on a client 
computer, assists the network manager manage the backup 
of workstations. For example, the administrator console will 
perform tasks such as job submission, viewing log files, 
database management, scheduling and the like. 

Back-up programs often include agents. An agent is a 
small piece of software that is stored on and processed by 
each workstation to perform slave tasks for the server. Thus, 
the agent runs on each computer to be backed up. The agent 
is not a complete computer program, but rather, a piece of 
software to support the server in completing a task defined 
for the workstation on which the agent is running. In backup 
programs, one job of the agent is to move data from the 
workstation to the server and receive data from the server 
and store it at the workstation. 
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Using agents to assist in the backup and restore process 
has a number of advantages. Because there is an agent 
running on each workstation (and each workstation, of 
course, has its own processor), processing can take place 

5 concurrently on each workstation. Commu nication overhead 
is reduced and network security is enhanced, as the agent 
can. for example, determine the content of a workstation's 
storage device and make decisions as to files to be backed 
up. without the need to provide the server with a list of files 

10 stored on the workstation. 

A disadvantage of current agent technology in backup 
programs results from the fact that agents are located at each 
workstation. Thus, if the network administrator wishes to 
update the backup program to a newer release of the 

15 program, the network administrator will often need to locate 
and update each agent on each workstation. Since there may 
be many workstations located in many physical locations, 
this could be a difficult and time consuming task. 
In particular, in a distributed application, it is difficult to 

20 synchronize the updating of agents on the plurality of 
workstations. 

The need to update agents is likely to become more 
common. For example, agents for various backup programs 
are often bundled with operating system programs for work- 

25 stations. A user will then purchase the backup program, 
comprising the backup engine and administrator console. 
The backup engine will communicate with each 
workstation, as each workstation has an agent preinstalled 
with the operating system. However, when the backup 

30 program is updated to a new release, the backup engine and 
administrator console can easily be replaced/updated, but it 
is difficult and time consuming to replace/update each agent 
There is also a need to apply updates and cause the 

35 updated agents to be available for use by the backup engine 
at the same time. 

SUMMARY OF THE INVENTION 
The present invention is directed to a method and system 
^ for updating or replacing agents stored and executing on a 
remote computer, in particular, a workstation in a client/ 
server network. In the representative embodiment, the 
agents are utilized in a backup software program and per- 
form slave tasks for a backup engine running on a central 

Each agent is a small piece of software that is stored and 
executes on each workstation to support the backup engine 
in completing a task defined for that workstation. Thus, in 
summary, each agent is a module that resides on a work- 

50 station that is being backed up or restored and performs, e.g.. 
file processing on that workstation. 

In the representative embodiment, the backup program 
that utilizes the present invention has three major compo- 
nents. The backup engine, located on the server, controls the 

ss writing of data to the backup storage device (for a backup 
job), controls the reading of data from the backup storage 
device (for a restore job), manages a task queue of jobs, and 
controls communications with the client computers. An 
administrator console, which runs on a client computer. 

60 enables management of the backup and restore operations. 
As stated above, an agent runs on each workstation to be 
backed up. 

For ease of explanation, when used herein, the term 
"backup" includes "restore", the term "update" includes 
65 "replace" and "modify", and the term "LAN" includes a 
wide area network ("WAN") and an enterprise wide net- 
work. 
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The updating of an agent occurs according to the repre- 
sentative embodiment of the present invention as follows. 
Assume that each agent is named Al. The backup engine 
electronically transmits, across the network to each 
workstation, a replacement agent file (A2) that comprises 
the executable code for the agent to replace Al. The backup 
engine also electronically transmits to each workstation an 
executable regeneration module, for example, named 
"Swapit". Al and Swapit are stored by Al at the worksta- 
tion. 

Optionally, each agent Al transmits a message to the 
backup engine verifying successful receipt of A2 and 
Swapit. 

Thereafter, the backup engine transmits to each worksta- 
tion (i.e., to Al on each workstation) an "execute/terminate" 
command. Each agent Al then loads and causes to be 
executed by its workstation the Swapit module, and then 
each agent Al terminates its own operation. 

The Swapit module, executing on each workstation, 
renames Al to preserve a copy of Al. The Swapit module 
then renames A2 to a new name appropriate for execution, 
for example, toAl.The Swapit module causes Al to execute 
or to be available for execution, for example, upon receipt of 
a command from the backup engine. 

If desirable, the present invention can be used to update 
a subset of the agents on a LAN. 

Each workstation may have more than one backup agent. 
The present invention is scalable and can easily accommo- 
date updating of more than one agent stored on a worksta- 
tion. 

If the update operation is not successful, the present 
invention has the capability to allow a graceful backing out 
of the process and restoration of the old agent (e.g.. Al in the 
example above). 

The present invention can coordinate the timing of the 
update. For example, for a large LAN. the transmission of 
the new agent (e.g. A2) can occur over a number of 
evenings, and execution of the Swapit module can take place 
on all workstations simultaneously. 

The backup agent of the present invention has capabilities 
to enable the efficient backup of the storage devices on all 
workstations on the network. When used in conjunction with 
the update process, network communication overheads are 
reduced. 

It will be noted, for example, that the backup engine need 
only communicate with the workstations on two occasions 
(when transferring the new agent and the Swapit module and 
when issuing the "execute/terminate" instruction). All pro- 
cessing is performed "automatically" either by the "old" 
agent or the Swapit module, both executing on the 
workstation, rather than in response to a series of commands 
from the server. 

Compression and decompression techniques also can be 
used to reduce transmission times and intermediate storage 
costs. 

BRIEF DESCRIPTION OF THE DRAWINGS 
The foregoing and other features of the present invention 

will be more readily apparent from the following detailed 

description of exemplary embodiments taken in conjunction 

with the attached drawings wherein: 
FIG. 1 is a system diagram of a network architecture 

utilized by the invention. 
FIG. 2 is a block diagram of an illustrative hardware 

configuration of a client system. 
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FIG. 3 is a flowchart of an exemplary update process of 
a representative embodiment of the present invention. 

FIG. 4 is a flowchart of the operation of an exemplary 
update module. 

5 

DETAILED DESCRIPTION 

Referring now to the drawings and initially FIG. 1. there 
is illustrated a diagram of a representative network used in 
conjunction with the present invention. A server 110 is 
coupled to client computers Cl-Cn through a network 120. 
The network 120 may be any type of network that supports 
computer-to-computer communication such as a local area 
network (LAN), a wide area network (WAN), or a public 
switched network (PSN) supporting any range of protocols 
such as TCP/IP. Ethernet. X.25. etc. The server 110 executes 
a backup engine program. The server 110 is coupled to a 
backup storage device (not shown). 
Each of the client computers Cl-Cn is a workstation 

2Q having an operating system program, such as. for example, 
the Windows 95 or Windows NT operating system Each 
client computer Cl-Cn stores and can execute (when 
instructed to do so by the backup engine) an agent. Each 
agent performs certain tasks for the backup engine at each of 

25 the client computers Cl-Cn. The agent is configured, for 
example, to open and/or connect to a socket and "listen" for 
commands directed to it from the backup engine on the 
server 110. For example, the backup engine may request that 
each agent "push" selected files to the server 110 so that the 

jq server 110 (under control of the backup engine) can copy the 
files to the backup storage device. 

The following is a more detailed illustrative description of 
some of the functions that can be performed by the agent of 
the present invention. A backup job may specify particular 

35 files that are to be backed up or criteria for files to be backed 
up (e.g.. all files created by Bob, all WordPerfect files, etc.). 
The backup job is created at the administrator console, 
which runs on a client computer (e.g. C2). and is executed 
by the backup engine on the server 110. If a specified file is 

40 to be backed up. the backup engine sends a request to the 
agent running on the client computer where the file is 
located, and the agent checks to see if the file is available for 
backup, and sends a copy of the file to the backup engine. If 
criteria is used to identify the files to be backed up. the 

45 backup engine provides the criteria to the agents on the 
appropriate client computers. Each agent will then traverse 
the directory structure of the storage devices. If a file is 
located by the agent that matches the criteria, a copy of the 
file is sent by the agent to the backup engine. Alternatively. 

so a circular buffer can be used — the agentA adds file names 
that match the criteria to the buffer and agentB performs the 
read/write operation to send that file to the backup engine. 
Thus, it will be seen that the agent supports, as a slave, the 
server in completing a task denned for that client computer. 

55 FIG. 2 illustrates in further detail the hardware configu- 
ration of the client computer (e.g.. CI) of FIG. 1. In the 
representative embodiment, the client computer CI com- 
prises a central processing unit 210 for executing computer 
programs (including the agent according to the present 

60 invention) and managing and controlling the operation of the 
client computer CI. Storage device 220. such as a floppy 
disk drive, is coupled to the central processing unit 210. 
Storage device 230. coupled to the central processing unit 
210. also provides a means for storing computer programs 

65 and data. Storage device 230 is preferably a hard disk having 
a high storage capacity. A dynamic memory device 240. such 
as a RAM. is coupled to the central processing unit 210. The 
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client computer CI includes typical input/output devices, 
such as. for example, a keyboard 250. a mouse 260 and a 
monitor 270. Each of the remaining client computers C2-Cn 
may be similarly configured. The server 110 may also be 
similarly configured but may further include connections to 
a plurality of high capacity storage media. 

According to the present invention, agent on each client 
computer Cl-Cn is updated from the server 110. Thus, the 
"new" agent is received from a storage device on the server. 
Alternatively, the "new" agent may be originally stored on. 
and therefore received from, any other computer connected 
to the network 120 and communicating with the client 
computers Cl-Cn. 

FIG. 3 is a flowchart illustrating a representative update 
process according to the present invention. 

In accordance with an exemplary embodiment of the 
invention, the backup engine first transmits (or causes to be 
transmitted) to each client computer Cl-Cn (or to a subset 
thereof) files containing the updated agent (step 310). Also 
transmitted is a "Swapit" module that is described in detail 
in connection with the flow chart of FIG. 4 (step 310). 

The "old" agent (executing on each client computer 
Cl-Cn) receives and stores the files transmitted by the 
workstation (step 310). The received files are stored locally 
at the client computer Cl-Cn (e.g.. in storage device 230) 
and may have a file extension of "new" to indicate a new file. 
Thus, for example, "agent.new" may represent the new 
executable agent (to be later renamed). The "old" agent may 
then optionally transmit messages back to the backup engine 
verifying the files were successfully received and stored 
(step 310a). 

Next, the backup engine transmits an "execute/terminate" 
command to the appropriate client computers Cl-Cn (step 
330). The execute/terminate command may include a 
parameter identifying a procedure for the client computer 
Cl-Cn to execute (e.g.. in this case "Swapit.") In response 
thereto, each agent loads and causes to be executed the 
program identified in the parameter, e.g., Swapit (step 340) 
and then shuts itself down (step 350). 

The flowchart of FIG. 4 provides details of an exemplary 
program flow of the Swapit module of steps 310 and 340 of 
FIG. 3. The Swapit module executes on each client computer 
Cl-Cn. The Swapit module may execute concurrently on 
each client computer Cl-Cn. Upon commencement of 
execution, the Swapit module renames the "old" agent to a 
new name so as to preserve a copy of that version of the 
agent (step 410). For example, "agentexe" may be renamed 
to "agent.old." (Alternatively, the Swapit module may sim- 
ply delete the old agent.) The Swapit module then renames 
the files associated with the updated agent to a new name 
appropriate for execution (step 410). Eg., "agent.new" is 
renamed to "agentexe." 

Once updated, the new agent can remain ready to act as 
the slave of the backup engine. Alternatively, it may be 
desirable to cause the new agent to execute upon the end of 
the update process. Thus, the following additional steps take 
place at the client computer. Subsequent to renaming all 
appropriate files, the Swapit module determines whether the 
old agent is still executing (step 420). This may be 
accomplished, for example, by invoking a Windows NT 
command which returns the "handle" of an executing mod- 
ule. If a handle is returned when the handle for the agent 
module is requested, the agent is still executing. In that case, 
the Swapit module waits for a predetermined length of time 
(step 430) and then checks again for a "handle" (step 420). 
If a handle is not returned, the old agent has terminated. The 
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Swapit module then starts the agent software, i.e.. the 
updated agent (step 440). 

It will be appreciate that steps 310 to 320 can be per- 
formed over a period of time, for example, when network 
5 use is low. Once all client computers Cl-Cn have received 
the updated agent and the Swapit module, then the "execute/ 
terminate" command can be sent substantially simulta- 
neously to all client computers Cl-Cn where updating is to 
take place. 

10 If desirable, the new agent and the Swapit module can be 
transmitted to the client computers Cl-Cn in one package 
or. alternatively, in separate files at separate times. 
Optionally, the new agent can delete the Swapit module. 

15 An variation to the above may include the transmission of 
software patch to the agent rather than a replacement agent. 
In that case, the Swapit module would i) make a backup 
copy of the old agent, ii) apply the software patches to the 
old agent, and iii) make the agent available for execution. 

20 In an alternative embodiment, the Swapit module can be 
configured to be self executing, for example, at a predeter- 
mined time. Thus, there would be no need for step 330. The 
Swapit module would, at step 350. determine if the agent 
was executing, and pause operation until a time when the 

25 agent was not executing. 

It will be appreciated that the principles of the present 
invention can be applied to the updating of any agent 
executing on a remote system, not merely backup agents. 
The agent and Swapit modules of the present invention 

30 can be implemented utilizing a logic circuit or a computer 
memory comprising encoded computer-readable 
instructions, such as a computer program. The functionality 
of the logic circuit or computer memory is described in 
detail above. 

While the present invention has been particularly shown 
and described with reference to exemplary embodiments 
thereof, it will be understood by those skilled in the art that 
various changes in form and details may be made therein 
40 without departing from the spirit and scope of the invention. 

What is claimed is: 

1. A method for updating an agent used in a backup 
software program, the backup software program operating 
on a network having a server and a plurality of workstations. 
45 the backup software program including a backup engine 
executing on the server and an agent executing on each 
workstation to be backed up, the method comprising the 

under the control of the backup engine, transmitting an 
50 updated agent to the agent at each workstation; 

under the control of the backup engine, transmitting an 
executable regeneration module to the agent at each 
workstation; 

under the control of the agent at each workstation, storing 
55 the updated agent and the executable regeneration 

module at each workstation; 
under the control of the backup engine, transmitting an 

execute command to the agent at each workstation; 
under the control of the agent at each workstation, causing 

the execution of the executable regeneration module; 
terminating the operation of the agent; 
under the control of the executable regeneration module at 

each workstation, deleting the agent; 
65 under the control of the executable regeneration module at 

each workstation, renaming the updated agent to the 

name of the agent; and 
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under the control of the executable regeneration module at 
each workstation, enabling operation of the updated 
agent as the agent. 

2. The method of claim 1 further comprising the step of, 
under the control of the agent at each workstation, notifying 
the backup engine of successful receipt of the updated agent 
and the executable regeneration module. 

3. The method of claim 1 further comprising the step of 
deleting the executable regeneration module. 

4. The method of claim 1 wherein the step of transmitting 
an execute command to the agent at each workstation occurs 
so as to enable simultaneous updating of each agent. 

5. A method for updating an agent used in a backup 
software program, the backup software program operating 
on a network having a server and a plurality of workstations, 
the server coupled to a backup storage device, the method 
comprising the steps of: 

providing a backup engine for execution on the server; 
providing an agent for execution on each of the plurality 

of workstations as a slave of the backup engine; 
under the control of the backup engine, transmitting an 

updated agent to each workstation; 
under the control of the backup engine, transmitting an 

executable regeneration module to each workstation; 
under the control of the agent at each workstation, storing 

the updated agent and the executable regeneration 

module at each workstation; 
under the control of the backup engine, transmitting an 

execute command to the agent at each workstation; 
under the control of the agent at each workstation, causing 

the execution of the executable regeneration module; 
terminating the operation of the agent; 
under the control of the executable regeration module at 

each workstation, renaming the agent to a recovery 

name; 

under the control of the executable regeneration module at 

each workstation, renaming the updated agent to the 

name of the agent; and 
under the control of the executable regeneration module at 

each workstation, enabling operation of the updated 

agent as the agent. 

6. The method of claim 5 further comprising to step of 
executing the agent at a workstation to assist the backup 
engine in a backup operation where files stored on the 
workstation are backed up across the network to the backup 
storage device. 

7. The method of claim 6 further comprising the step of. 
under the control of the agent at each workstation, notifying 
the backup engine of successful receipt of the updated agent 
and the executable regeneration module. 

8. The method of claim 6 further comprising the step of 
deleting the executable regeneration module. 

9. The method of claim 6 wherein the step of transmitting 
an execute command to the agent at each workstation occurs 
so as to enable simultaneous updating of each agent. 



10. The method of claim 5 further comprising the step of 
restoring the agent by renaming the agent having the recov- 
ery name to be that of the agent. 

11. A system for updating an agent used in a backup 
5 software program, the backup software program operating 

on a network having a server and a plurality of workstations, 
the system comprising: 
a backup engine executing on the server; and 
10 an agent executing on each of the plurality of worksta- 
tions to be backed up; 
the backup engine transmitting an updated agent to each 
workstation and transmitting an executable regenera- 
tion module to each workstation and transmitting an 
15 execute command to the agent at each workstation; 
the agent at each workstation storing the updated agent 
and the executable regeneration module at each work- 
station and causing the execution of the executable 
20 regeneration module; 

the executable regeration module at each workstation, 
deleting the agent and renaming the updated agent to 
the name of the agent and thereafter enabling operation 
of the updated agent as the agent. 
25 12. A system for updating an agent used in a backup 
software program, the backup software program operating 
on a network having a server and a plurality of workstations, 
the server coupled to a backup storage device, the system 
comprising: 

30 a backup engine for execution on the server, the backup 



means for transmitting an updated agent to each 
workstation. 

means for transmitting an executable regeneration 
35 module to each workstation, and 

means for transmitting an execute command to the 
agent at each workstation; and 
an agent at each workstation, the agent including 
means for storing the updated agent and the executable 
40 regeneration module at each workstation, and 

causing the execution of the executable regeneration 
module; 

wherein the executable regeration module at each worksta- 
45 tion renames the agent to a recovery name, renames the 
updated agent to the name of the agent, and enables opera- 
tion of the updated agent as the agent 

13. The system of claim 12 further comprising means for 
executing the agent at a workstation to assist the backup 

50 engine in a backup operation where files stored on the 
workstation are backed up across the network to the backup 
storage device. 

14. The system of claim 12 further comprising means for 
notifying the backup engine of successful receipt of the 

55 updated agent and the executable regeneration module. 
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ABSTRACT 



A method and apparatus for downloading tone data from a 
public land mobile network to a mobile telephone unit is 
disclosed. A mobile telephone unit includes means enabling 
the user to request downloading of tone data to the mobile 
telephone unit from a public land mobile network via a 
connection-less communications link such as the USSD or 
SMS. The downloaded tone data is uniquely associated with 
a selected telephone number within the mobile telephone 
unit such that a call to the mobile unit involving the 
telephone number initiates audio play back of the tone data. 

54 Claims, 4 Drawing Sheets 
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METHOD AND APPARATUS FOR to the following Detailed Description when taken in con- 

DOWNLOADING TONES TO MOBILE junction with the accompanying Drawings wherein: 

TERMINALS FIG. 1 is a block diagram illustrating the communication 

„ . „ T , „ m „^ , of a short message service (SMS) messages between a SMS 

BACKGROUND OF THE INVENTION s operator and a mobile station; 

1. Technical Field of the Invention FIG. 2 is a block diagram illustrating the communication 
The present invention relates to personal communication °f an unstructured supplemental services data (USSD) mes- 

systems, and more particularly, to the downloading of tone sa 8 es between a USSD external node user and a mobile 

data to a mobile terminal to enable the playing of the tones station; 

in association with a particular telephone number. 10 FIG- 3 is a block diagram illustrating the components 

2. Description of Related Art necessary for downloading of tones between a PLMN and 
The ever expanding list of services available via personal mobile unit; and 

communication services (PCS) systems have provided PCS FIG - 4 15 a block diagram illustrating the manner through 

users with the ability to select a number of services from whlch a user interactively downloads tones to a subscriber 
their mobile telephone unit in addition to the standard 15 lde ntity module ( SIM ) card. 

telephone communication services. A number of these ser- DETAILED DESCRIPTION OF THE DRAWINGS 

vices require the user to view some type of graphical or Telecommunication services are normally performed in a 

alphanumeric display upon the mobile telephone unit. Hav- structured Fof j ific ^ defined d 

mg to view the display can in some cases be inconvenient, formatS) and gi { names are ^ t0 ^ a h 

for example if the user happens to be driving, if the connecti t0 form handoverS) and t0 authen ticate 

telephone is located in the user's pocket or briefcase or if mobile subscriber information when providing te lecommu- 

the user is involved m activity precluding the use of their nicatk)n tQ a mobile subscriber . with * he 

hands. Thus, it would be beneficial to enable the user to ^ of ^ bbal fof mobile (GSM) 

know who is callmg without having to check the calling ^ and the personal communications systems (PCS); a 

num er isp ay. 0 ^ Qew and a( j vance( j supplementary services are being 

In other cases usmg existing PCS technologies, the user prov ided to mobile subscribers. Since these supplementary 

may have more than one telephone number associated with services milize user specified data> there are no struc tured 

a particular mobile telephone unit, for example, a personal ways t0 C o mmU nicate this data between the public land 

telephone number and a business telephone number. The mobile network (pLMN) and a mobile station . M a result; 

user can benefit by knowing whether the personal or busi- a number of unstructured business prot ocols have been 

ness number has been called by the use of an indicator that developed for the GSM or PCS environments. As the 

a~. ^ t require the user to look at the phone. This will transmission of tone data between a PLMN and a mobile 



enable the user to answer the mobile telephone unit differ- 



t falls under the category of transmitting unstructured 



ently based upon whether the business number or personal U ser data, the transfer would be controlled by one of these 

number was called. Thus, a mobile telephone unit providing protocols 

the user with the option to select and download new tones to Qnce guch ^ ^ unst ructured supplementary service 

be used for different call scenarios would provide an ease of data (USSD) whkh faas been introdu ^ d t0 en able user 

use and flexibility that would greatly benefit the user. interaction between PLMN applications and a mobile station 

SUMMARY OF THE INVENTION 40 in a transparent way through a mobile telecommunication 



The present invention overcomes the foregoing and other network. The communication is transparent because no 

problems with a method and apparatus for downloading tone review or manipulation of the contents of the message is 

data between a public land mobile network (PLMN) and a performed during the transportation period, 

mobile unit. A mobile unit includes a client application for 0n e type of user specified information that may be 

requesting the downloading of tone data from a PLMN 45 transmitted between a PLMN and a mobile telephone unit is 

through a connection-less communications link. Requests ton e data, which then may be associated with called c 



from the client application are received by a server appli- callln g numbers in a manner designated by the user. Refer- 

cation located within the public land mobile network. The ence is now made to FIG. 1, where a block diagram 

server application is normally associated with the mobile generally illustrates the communication of a short message 

switching center (MSC). The server application provides so service (SMS) message between an SMS operator 10 and 

access to a tone data base wherein a user may select a tone mobile station 20. The SMS operator 10 sends data to the 

for downloading through the mobile unit's user interface. short message service center (SMS-C) 30 to be transmitted 

Once a tone is selected, the tone data associated with the t0 the mobile station 20 ^ SMC " C 30 encapsulates the 

tone is downloaded to the mobile unit via the connection- entered data int ° « P acket messa S e ' such 88 signaling system 

less user interface. The interface preferably comprises either 55 number 7 (SS 7) signals or X.25 protocol packets, and routes 

short message service (SMS) messages or unstructured the messa § e «? a short messa § e service-gateway mobile 

supplemental services data (USSD) messages which are switch center (SMS-GMSC) 40 within a PLMN 50 serving 

useful for downloading unstructured user designated data. ' he mobile station 20. The SMS-GMSC 40 interrogates a 

The downloaded tone data is then uniquely associated with home location register (HLR) 60 associated with the mobile 

a selected called or calling party telephone number, or group <*° unlt 20 for routin § information (i.e., an identification where 

of numbers, such that when a call to the mobile unit involves the mobile station 20 15 located ) and subsequently 

the selected telephone number, an audio play back of the routes the message to a mobile switching center (MSC) 70 

tone data is initiated. serving the mobile station's current location. The mobile 

station 20 is paged and a connection is set up between the 

BRIEF DESCRIPTION OF THE DRAWINGS 65 mo bile station and the PLMN 50. 

A more complete understanding of the method and appa- If the mobile station 20 is already busy, the connection 

ratus of the present invention may be obtained by reference setup is not performed because the network already knows 
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the mobile station 20 is accessible. If the connection has 
been successful and thereby the mobile station 20 
authenticated, the MSC 70 encapsulates the tone data into an 
SMS message 80 and delivers the SMS message to the 
mobile station 20 over one of the control data channels. The 5 
control data channel such as a stand alone dedicated control 
channel (SDCCH) is used instead of a traffic channel (TCH) 
to allow connection-less data communication. After receiv- 
ing the SMS message 80 encapsulating the tone data, the 
mobile station acts merely as a buffer and passes the data to 1Q 
the attached subscriber identity module (SIM) card 90. The 
SIM card 90 then stores the received data into an internal 
buffer or memory register. Lastly, if the delivery has been 
successful, a successful delivery report is sent back from the 
MS 20 to the serving MSC 70, and subsequently from the 15 
serving MSC 70 to the SMS-C 30. Otherwise, a failure 
report is generated. 

With respect to a mobile originated SMS message (MO- 
SMS) a user at a mobile station 20 can initiate an SMS signal 
to request downloading of data, such as tone data. The 20 
mobile station 20 makes a request to the mobile switching 
center (MSC) 70 to transmit tone data to the mobile station 
20. The MSC 70 encapsulates the request into a packet 
message, and routes the message to a short message service 
gateway mobile switch center (SMS-GMSC) 40 within a 25 
PLMN 50 serving the mobile station 20. The SMS-GMSC 
40 retrieves the requested data and subsequently routes a 
message to the MSC 70 serving the mobile station's current 
location. The mobile station 20 is then paged and a connec- 
tion is set up between the mobile station and the PLMN 50. 30 
The MSC 70 encapsulates the tone data into an SMS 
message 80 and delivers the SMS message to the mobile 
station 20 over one of the control data channels. The data is 
then stored within the SIM card 90 as previously described. 

FIG. 2 is a block diagram illustrating the communication 35 
of a USSD message between a USSD external node user 100 
and a mobile station 20. USSD messages are utilized by the 
mobile telecommunications network to transport user 
defined data to a mobile station 20 or an application module 
within a mobile station. Therefore, instead of storing and 40 
receiving character data into a SIM card, the received data 
is either manipulated by the feature application modules 
within the receiving mobile station to provide special sub- 
scriber feature functions, or it is displayed on a display unit 
for user interactions. 45 

The external node user 100 transmits the USSD message 
encapsulating the tone data to the HLR 60 within the serving 
PLMN 50. The HLR 60 is associated within a number of 
different MSC's within the same PLMN 50. As the mobile 
station 20 travels from one MSC's area to another, the HLR 50 
receives location update signals into record of the mobile 
station's current location. Whenever a USSD signal is 
received by the HLR, the HLR ascertains a current location 
of the mobile station 20. The USSD handler 110 within the 
HLR 60 thereafter transparently forwards the USSD signal 55 
to the appropriate MSC 70 currently serving the mobile 
station 20. The USSD handler 120 within the serving MSC 
70 receives the transmitted message and transports the 
USSD message 130 to the mobile station 20 over a 
connection-less communications link. The USSD handler 60 
140 within the mobile station 20 then receives the transmit- 
ted USSD message 130, extracts encapsulated tone data, and 
forwards the extracted data to the appropriate application 
module. 

Referring now to FIG. 3 where a block diagram illustrates 65 
the components necessary for downloading tones requested 
by a subscriber (user). The subscriber requests access to a 



tone database 150 containing a variety of predetermined data 
packages representing a particular tone or group of tones to 
be played by the audio output 155 of the mobile unit 20 in 
response to a particular calling or called number. The client 
application 160 within the mobile unit 20 initiates a request 
for access to the tone database in response to inputs by the 
user through the user interface 165. The client application 
160 actuates a serving application 170 located with the 
PLMN. The serving application 170 may be located with the 
MSC/VLR, the HLR, or some other external node. The 
serving application 170 connects the user with the database 
150 using either the SMS or USSD protocols discussed 
earlier. The user then selects desired tones in a manner which 
will be more fully described with respect to FIG. 4. 

The tone data associated with the tone selected from the 
tone database 150 is downloaded to the client application 
160 as a digitally coded tone pattern using either the USSD 
or SMS protocols described previously with respect to 
FIGS. 1 and 2. The above-described manner of downloading 
a tone from the tone database 150 is utilized with respect to 
menu driven options solely using SMS or USSD messages, 
optionally, an audio menu may be provided to the user such 
that an actual connection is generated between the mobile 
station 20 and the tone database 150. In this case, an audio 
version of the tones would be played for the user and the 
client application 160 would record the tone and convert it 
to a digital format for storage in the SIM card 90. 

In the case of a transmission using a SMS message, the 
serving MSC 70 receives the transmitted tone signal from 
the SMS-GSMC 40 and then transmits an SMS message 
encapsulating the tone data to the mobile unit station 20 over 
a connection-less communication link such as SDCCH. The 
client application 160 within the mobile unit 20 acts as a 
buffer for the SMS message and passes the tone data from 
the message to the SIM card 90. The user may then, through 
client application 160, associate the tone within the SIM 
card 90 with a particular calling or called telephone number. 

If a USSD message is used for downloading, the tone data 
is routed to the mobile station 20 by a USSD handler 120 
within the serving MSC 70 as a USSD message encapsu- 
lating the tone data over a connection-less communication 
link such as SDCCH. USSD handler 140 within the mobile 
station receives the transmitted USSD message and forwards 
the message to the client application 160 for extraction of the 
tone data. The extracted tone data is then stored within the 
SIM card 90. Through the client application 160, the user 
may then uniquely associate the tone with a particular 
calling or called telephone number. 

Once the tone data is downloaded into the SIM card 90 of 
the mobile unit 20 and associated with a particular telephone 
number, the receipt of an incoming call actuates ring logic 
200 within the mobile terminal 20. The ring logic 200 checks 
for the presence of tone pattern associated with the number 
called or the number of the party calling. If such an 
association is found, the tone data is played by the audio 
output 155 to provide an audio indicator to the user of who 
is calling or which of the user's numbers is being called. 

Referring now to FIG. 4, there is illustrated the procedure 
by which a user may download a particular tone pattern from 
the tone database 150. Once the mobile unit 20 has inter- 
connected with the tone database 150, the mobile unit user 
is presented at step 260 with a variety of menus enabling the 
selection of tones by the user. The menus may break the 
tones down in a variety of manners such as alphabetically, 
by music type, by novelty items, etc. Once a particular tone 
is selected, the user may play a sample tone at step 270 to 
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preview what the tone sounds like. When a desired tone or 
tone pattern is found, the user may instruct the application 
160 to download the tones at step 280. Otherwise, a user 
may return to previous menus at step 300. 

Although an embodiment of the method and apparatus of 
the present invention has been illustrated in the accompa- 
nying Drawings and described in the foregoing Detailed 
Description, it will be understood that the invention is not 
limited to the embodiment disclosed, but is capable of 
numerous rearrangements, modifications and substitutions 
without departing from the spirit of the invention as set forth 
and defined by the following claims. 

What is claimed is: 

1. A mobile station, comprising: 

a receiver for receiving tone data over a wireless 
connection-less communications link from a public 
land mobile network; 

a subscriber identity module card for storing the tone data; 
and 

means for requesting downloading of the tone data to the 
subscriber identity module card from the public land 
mobile network over the wireless connection-less com- 
munications link and for associating a telephone num- 
ber with the tone data such that call connections 
involving the telephone number initiate audio playback 
of the tone data. 

2. The mobile station according to claim 1, wherein the 
wireless connection-less communications link comprises 
short message service messages. 

3. The mobile station according to claim 1, wherein the 
wireless connection-less communications link comprises 
unstructured supplementary service data messages. 

4. The mobile station according to claim 1, wherein the 
telephone number comprises a telephone number of a calling 
party. 

5. The mobile station according to claim 1, wherein the 
telephone number comprises a telephone number of a called 
party. 

6. The mobile station according to claim 1, further com- 
prising control logic for determining if an incoming call 
involves the telephone number and initiating audio playback 
of the tone data for incoming calls involving the telephone 
number. 

7. A system for downloading tone data to a mobile station, 
comprising: 

a public land mobile network serving said mobile station, 
said public land mobile network including a first appli- 
cation module responsive to a request from the mobile 
station for downloading said tone data to the mobile 
station via a wireless connection-less communications 
link; and 

said mobile station comprising: 

a subscriber identity module card for storing said tone 

a receiver for receiving said tone data from the public 
land mobile network over the wireless connection- 
less communications link; and 

means for requesting downloading of the tone data to 
the subscriber identity module card from the public 
land mobile network over the wireless connection- 
less communications link and for associating a tele- 
phone number with the tone data such that call 
connections involving the telephone number initiate 
audio playback of the tone data. 

8. The system according to claim 7, wherein the wireless 
connection-less communications link comprises short mes- 
sage service messages. 
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9. The system according to claim 7, wherein the wireless 
connection-less communications link comprises unstruc- 
tured supplementary service data messages. 

10. The system according to claim 7, wherein the tele- 
5 phone number comprises a telephone number of a calling 

party. 

11. The system according to claim 7, wherein the tele- 
phone number comprises a telephone number of a called 
party. 

1Q 12. The system according to claim 7, further comprising 
control logic for determining if an incoming call involves 
the telephone number and initiating audio playback of the 
tone data for incoming calls involving the telephone number. 

13. A method for downloading tone data, comprising the 
steps of: 

15 accessing a public land mobile network using a wireless 
communications link from a mobile unit; 
requesting access to tone data located within the public 
land mobile network from a client application within 
the mobile unit; 
20 downloading the requested tone data to a subscriber 
identity module card of the mobile unit through said 
wireless connection-less communications link; and 
associating the downloaded tone data with a selected 
telephone number. 
25 14. The method according to claim 13, further comprising 
the step of playing an audio rendition of the tone data in 
response to receipt by the mobile unit of a call involving the 
selected telephone number. 

15. The mobile station according to claim 13, wherein the 
30 wireless communications link comprises short message ser- 
vice messages. 

16. The mobile station claim 13, wherein the wireless 
communications link comprises unstructured supplementary 
service data messages. 

35 17. The mobile station according to claim 13, wherein the 
telephone number comprises a telephone number of a calling 
party. 

18. The mobile station according to claim 13, wherein the 
telephone number comprises a telephone number of a called 

40 party. 

19. The mobile station according to claim 13, wherein 
said step of requesting access provides audio playback of the 
tone data. 

20. The mobile station according to claim 13, wherein 
45 said step of requesting access provides a text selection of the 

tone data. 

21. A mobile station, comprising: 

a receiver for receiving tone data over a connection-less 
communications link from a public land mobile net- 

50 work ; 

a register for storing the tone data; and 

means for requesting downloading of the tone data to the 
register from the public land mobile network over the 
connection-less communications link and for associat- 
55 ing a telephone number with the tone data such that call 
connections involving the telephone number initiate 
audio playback of the tone data, 

wherein said connection-less communications link com- 
prises a link selected from the group consisting of short 
60 message service messages and unstructured supple- 
mentary service data messages. 

22. The mobile station according to claim 21, wherein the 
register comprises a subscriber identity module card attach- 
able to the mobile station. 

65 23. The mobile station according to claim 21, wherein the 
telephone number comprises a telephone number of a calling 
party. 
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24. The mobile station according to claim 21, wherein the 
telephone number comprises a telephone number of a called 
party. 

25. The mobile station according to claim 21, further 
comprising control control logic for determining if an 
incoming call involves the telephone number and initiating 
audio playback o the tone data for incoming calls involving 
the telephone number. 

26. A mobile station, comprising: 

a receiver for receiving tone data over a connection-less 
communications link from a public land mobile net- 
work; 

a register for storing the tone data; and 

means for requesting downloading of the time data to the 
register from the public land mobile network over the 
connection-less communications link and for associat- 
ing a telephone number with the tone data such that call 
connections involving the telephone number initiate 
audio playback of the tone data, wherein said telephone 
number comprises a telephone number of a called party. 

27. The mobile station according to claim 26, wherein the 
register comprises a subscriber identity module card attach- 
able to the mobile station. 

28. The mobile station according to claim 26, wherein the 
connection-less communications link comprises short mes- 
sage service messages. 

29. The mobile station according to claim 26, wherein the 
connection-less communications link comprises unstruc- 
tured supplementary service data messages. 

30. The mobile station according to claim 26, wherein the 
telephone number comprises a telephone number of a calling 
party. 

31. The mobile station according to claim 26, further 
comprising control logic for determining if an incoming call 
involves the telephone number and initiating audio playback 
of the tone data for incoming calls involving the telephone 
number. 

32. A system for downloading tone data to a mobile 
station, comprising: 

a public land mobile network serving said mobile station, 
said public land mobile network including a first appli- 
cation module responsive to a request from the mobile 
station for downloading said tone data to the mobile 
station via a connection-less communications link; and 
said mobile station comprising: 

a register for storing said tone data; 
a receiver for receiving said tone data from the public 
land mobile network over the connection-less com- 
munications link; and 
means for requesting downloading of the tone data to 
the register from the public land mobile network 
over the connection-less communications link and 
for associating a telephone number with the tone data 
such that call connections involving the telephone 
number initiate audio playback of the tone data, 
wherein said connection-less communications link 
comprises a link selected from the group consisting 
of short message service messages and unstructured 
supplementary service data messages. 

33. The system according to claim 32, wherein the tele- 
phone number comprises a telephone number of a calling 
party. 

34. The system according to claim 32, wherein the tele- 
phone number comprises a telephone number of a called 
party. 

35. The system according to claim 32, further comprising 
control logic for determining if an incoming call involves 
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the telephone number and initiating audio playback of the 
tone data for incoming calls involving the telephone number. 

36. A system for downloading tone data to a mobile 
station, comprising: 

5 a public land mobile network serving said mobile station, 
said public land mobile network including a first appli- 
cation module responsive to a request from the mobile 
station for downloading said tone data to the mobile 
station via a connection-less communications link; and 
10 said mobile station comprising: 

a register for storing said time data; 
a receiver for receiving said tone data from the public 
land mobile network over the connection-less com- 
munications link; and 
means for requesting downloading of the tone data to 
1 the register from the public land mobile network 

over the connection-less communications link and 
for associating a telephone number with the tone data 
such that call connections involving the telephone 
number initiate audio playback of the tone data, 
20 wherein said telephone number comprises a tele- 

phone number of a called party. 

37. The system according to claim 36, wherein the register 
comprises a subscriber identity module card attachable to 
the mobile station. 

25 38. The system according to claim 36, wherein said 
connection-less communications link comprises short mes- 
sage service messages. 

39. The system according to claim 36, wherein said 
connection-less communications link comprises unstruc- 

30 hired supplementary service data messages. 

40. The system according to claim 36, wherein the tele- 
phone number comprises a telephone number of a calling 
party. 

41. The system according to claim 36, further comprising 
35 control logic for determining if an incoming call involves 

the telephone number and initiating audio playback of the 
tone data for incoming calls involving the telephone number. 

42. A method for downloading tone data, comprising the 
steps of; 

40 accessing a public land mobile network using a commu- 
nications link from a mobile unit, said communications 
link comprising a link selected from the group consist- 
ing of short message service messages and unstructured 
supplementing service data messages; 

45 requesting access to tone data located within the public 
land mobile network from a client application within 
the mobile unit; 
downloading the requested tone data to the mobile unit 
through said communications link; and 

50 associating the downloaded tone data with a selected 
telephone number. 

43. The method according to claim 42, further comprising 
the step of playing an audio rendition of the tone data in 
response to receipt by the mobile unit of a call involving the 

55 selected telephone number. 

44. The method according to claim 42, wherein the 
telephone number comprises a telephone number of a calling 
party. 

45. The method according to claim 42, wherein the 
60 telephone number comprises a telephone number of a called 

party. 

46. The method according to claim 42, wherein said step 
of requesting access provides audio playback of the tone 

65 47. The method according to claim 42, wherein said step 
of requesting access provides a text selection of the tone 
data. 
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48. A method for downloading tone data, comprising the 
steps of: 

accessing a public land mobile network using a commu- 
nications link from a mobile unit; 

requesting access to tone data located within the public 5 
land mobile network from a client application within 
the mobile unit; 

downloading the requested tone data to the mobile unit 
through said communications link; and 1Q 

associating the downloaded tone data with a selected 
telephone number, said selected telephone number 
comprising a telephone number of a called party. 

49. The method according to claim 48, further comprising 
the step of playing an audio rendition of the tone data in 15 
response to receipt by the mobile unit of a call involving the 
selected telephone number. 
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50. The method according to claim 48, wherein said 
communications link comprises short message service mes- 
sages. 

51. The method according to claim 48, wherein said 
communications link comprises unstructured supplementary 
service data messages. 

52. The method according to claim 48, wherein the 
telephone number comprises a telephone number of a calling 
party. 

53. The method according to claim 48, wherein said step 
of requesting access provides audio playback of the tone 

54. The method according to claim 48, wherein said step 
of requesting access provides a text selection of the tone 
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ABSTRACT 



A personal communications internetwork provides a per- 
sonal communications internetwork providing a network 
subscriber with the ability to remotely control the receipt 
and delivery of wireless and wireline electronic text mes- 
sages. The network operates as an interface between wire- 
less and wireline networks. The subscriber's message 
receipt and delivery options are maintained in a database 
which the subscriber may access by wireless or wireline 
communications to update the options programmed in the 
database. 

3 Claims, 21 Drawing Sheets 
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FIG. 2 
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ELECTRONIC MASSAGING NETWORK 
RELATED CASE INFORMATION 
This case is a continuation application of U.S. patent 
application Ser. No. 08/309336 filed on Sep. 19, 1994. The 
contents of that application are incorporated herein by 
reference. 

FIELD OF THE INVENTION 

The present invention is directed to an internetwork for 
personal communications and, more particularly, to a net- 
work which provides a variety of electronic text delivery, 
receipt, and notification options. 

BACKGROUND OF THE INVENTION 

The use of messaging as a means of day-to-day commu- 
nications continues to grow and evolve, particularly in a 
business context. Messaging includes electronic mail 
(e-mail), facsimile transmissions (fax), paging, voice mail, 
and telephone communications. The introduction of the 
cellular phone and other wireless communications facili- 
tated the advent of the "mobile office". The mobile office 
allows an employee, for example, to work away from the 
office on a portable computer and be in constant touch with 
the office via a cellular phone. 

The messaging options described above are available to 
businesses of all sizes, as well as individual users, from a 
variety of service providers. Many offices have some or all 
of the messaging options described above. The office may 
have certain messaging equipment (referred to as "consumer 
premises equipment" or "CPE") connected to one or more 
wireline networks. That is, the office may have telephones, 
fax servers, and voice mail systems connected to phone 
lines, and computers having modems for e-mail connected 
to packet networks which are connected via phone lines. The 
mobile employee may have certain wireless messaging 
equipment, such as a pager, a cellular telephone, or a 
personal digital assistant ("PDA"), which is typically a 
notebook computer connected to a wireless communication 
network. 

One important goal of personal communication services is 
to allow users to communicate from anywhere to anywhere 
at any time. Such personal communication services gener- 
ally involve multiple service providers including local and 
long distance telephone companies and cellular telephone 
companies. An example of a personal communication ser- 
vice is as follows: 

A personal communication service provider (e.g., a cel- 
lular telephone company) enables traveling users to rent a 
wireless portable phone from a rental phone company (e.g., 
from an airline or car rental company). Using the rental 
phone, the user is provided with basic mobile phone service 
from the personal communication service provider. In 
addition, the user would like the following features: 

1) The user wants calls directed to his/her office or home 
to be automatically forwarded to the rental portable phone, 
without informing anyone that he/she is traveling. 

2) To avoid unimportant incoming calls (and correspond- 
ing incoming call charges), the user would like to restrict the 
number of people who can call the rented portable phone. 

3) It is important to the user that the rental phone features 
be activated instandy, so that calls can be made immediately 
upon the user's arrival at the visiting location. 

This kind of personal communication service involves a 
plurality of service providers. These providers are (a) the 
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local telephone company at the home location, (b) a long 
distance telephone company, (c) the local telephone com- 
pany at the visiting location, and (d) the personal commu- 
nication service provider (i.e., the cellular telephone 
5 company) at the visiting location. All of these are referred to 
herein as "service providers". 

To enable this kind of personal communication service, 
involving multiple service providers, interoperability prob- 
lems among the different service providers must be resolved. 
10 The interoperability problems can be divided into two 
categories: (a) location tracking and (b) service manage- 
ment 

The interoperability problem for location tracking has 
been addressed by adopting signaling protocols used by the 
15 mobile phone industry. Location tracking functions are 
implemented using two location registers. One of the 
registers, maintained by the local telephone company of the 
user's home location, is called the Home Location Register 
(HLR). The other register, maintained by the local telephone 
20 company of the visiting location, is called the Visiting 
Location Register (VLR). The HLR stores customer profile 
data and the location of the VLR of the user. The customer 
profile data contains important information such as the 
user's name, address, preferred long distance carrier, service 
25 features (e.g., call forwarding and call restriction), billing, 
and other administrative related information. When the user 
travels to a new visiting location, a new VLR is created in 
the new location. Apart of the profile data stored in the HLR 
is transmitted and loaded into the VLR such that the service 
30 provider at the visiting location can implement service 
features for the visiting user. When the user travels to a new 
visiting location the location of the VLR stored in the HLR 
is changed to the new VLR location, and the VLR in the 
previously visited location is deleted. The process of creat- 
35 ing a new VLR, loading profile data to the VLR, and 
updating the visiting location of a user in the HLR is called 
"automatic roamer registration". 

The interoperability problem for service management is 
much more complex than mat for location tracking. Service 
40 management refers to a collection of functions required to 
enable a personal communication service user to subscribe 
to, modify, and activate service features anywhere and at any 
time. Examples of service management functions include 
phone number administration, customer profile data 
45 management, service activation, and security administra- 
tion. The phone number administration function is important 
for maintaining the uniqueness of phone numbers. The 
customer profile data management function provides cus- 
tomer profile databases and user interfaces for creating, 
so modifying, or transferring such databases. The service acti- 
vation function extracts part of the data specifying service 
features from the profile data and loads this data into 
physical communication systems that process calls. The 
service activation function also controls the activation and 
55 deactivation of the service features. The security adminis- 
tration function prevents or detects unauthorized uses of 
services and service management functions. 

Service management functions of this type are needed to 
provide personal communication services involving mul- 
60 tiple service providers. Such service management functions 
generally require interactions between application software 
and various databases owned and operated by the different 
service providers. Consider an application which enables a 
nomadic user to subscribe to a personal communication 
65 service from any service provider at any location. An 
example of such a service is call forwarding to a temporarily 
rented portable phone. The application may, for example. 
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need to perform the following database access operations at FIG. 7 is a block diagram of the logical connections 

databases maintained by various different service providers: between the PCI server and PCI database according to the 

check credit databases owned by credit card companies or present invention; 

phone companies to determine whether the user is able FIGS. 8, 9, and 10 illustrate exemplary message flows 

to pay for the service; 5 between a server and a database according to the present 

check the customer profile database in the user's HLR to invention; 

determine whether the user is currently located in a FIG. 11 is a block diagram of a personal digital assistant 

place other than the visiting location currently stored in according to the present invention; 

*e HLR; FIGS. 12, 13, 14, 15a. 15b, 16, 17, 18a and lSb illustrate 

check the credit and network databases of long distance exemplary message flows between a PDA and PCI server; 

phone companies specified by the user to determine nG 19is& block of a text messaging portion of 

whether the user can use a particular long distance a pQ network; 

carrier in the visiting location; FIGS. 20, 21, and 22 illustrate exemplary message flows 

load profile data into the VLR at the visiting location and in the Pa network; and 

update the HLR with the location of the VLR if ^ ^ ^ ^ ^ ^ ^ ^ and ^ mm 

necessary, an exemplary screens displayed to a PCI subscriber using a 

load the profile data to the call processing systems and wjjeiess PDA 

activate the service. 

The user may need to send or receive messages from any 20 DETAILED DESCRIPTIONS OF PREFERRED 

or all of the messaging options described above at a visiting EMBODIMENTS 
location. That is, the user may want to receive or receive 

notification of e-mail, faxes, phone calls, or voice mail at a For clarity of presentation, the detailed description is set 

visiting location or to send e-mail or faxes from a wireless out in the following subsections: 

terminal. The need to integrate these various types of 2 s I- p G Overview 

messaging options and to interconnect the many service The overall network is illustrated in FIGS. 1-4 The 

providers has, until now, been largely unaddressed. network is an interface between a plurality of wireless and 

It is also desirable for the mobile employee to be able to wireline networks, providing a subscriber with a variety of 

limit the messages sent to the wireless messaging wireless and wireline message and voice delivery and 

equipment, so that only urgent messages are received when 30 receipt options, 

away from the office and unwanted in-coming calls are H The PCI Server 

avoided. The mobile employee may also wish to route The PCI Server is illustrated in FIG. 5. The PCI server is 

certain incoming wireless messages and phone calls to other a peripheral which performs messaging and call redirection 

destinations, such as an office fax machine or a colleague's functions and interfaces with the PCI database to update the 

telephone. 35 subscriber profile. 

Therefore, it is an object of the present invention to HI. The PCI Database 

provide a mobile service subscriber the ability to remotely The PCI Database is illustrated in FIG. 6. The PCI 

control the addressability, routing, accessibility, and delivery database maintains the subscriber profile, controls CallCom- 

of messaging options. mand functions, and handles DTMF-based subscriber profile 

It is another object of the present invention to provide an 40 updates, 

internetwork which interconnects messaging services with IV. The Server/Database Interface 

bom wireless and wireline networks. The Server/Database interface is illustrated in FIGS. 

It is yet a further object of the invention to provide a 7-10. The PCI server/PCI database interface provides for the 

control over the messages routed to wireless messaging transfer of information regarding the subscriber profile, 

options. 45 V. The PDA/PCI Interface 

„, The PDA/Pa interface is illustrated in FIGS. 11-18. The 

SUMMARY OF THE INVENTION PDA/PCI interface provides for the transfer of information 

These objects are obtained by a personal communications between a remote wireless subscriber and the PCL 

internetwork providing a network subscriber with the ability VI. E-mail Messaging Services 

to remotely control the receipt and delivery of wireless and 50 E-mail messaging is the PCI in illustrated in FIG. 19. The 
wireline electronic text ("e-mail") messages. The network PCI network provides the subscriber with a variety of e-mail 
operates as an interface between wireless and wireline delivery, receipt, and notification options, including screen- 
networks, The subscriber's message receipt and delivery ing and selective destination delivery of incoming e-mail, 
options are maintained in a database which the subscriber VTL Message Flows 

may access by wireless or wireline communications to 55 Certain message flows for wireless messaging in the PCI 

update the options programmed in the database. are illustrated in FIGS. 20-22. The three message flows 

rwtbp np^rRiPTrnisr df thf nrc awtnos illustrated are sending a message from one subscriber to 

BRIEF DESCRIPTION OF THE DRAWINGS receiving a message regardless of whether the 

These and other objects and features of the invention will subscriber is using a wireless or wireline terminal, and 

become apparent from the following drawings, wherein: ^ sending a message to a non-subscriber. 

FIG. 1. 2, and 3 are overviews of the PCI networks; VHI. The PDA Application 

FIG. 4 is an overview of one node of the PCI network The application residing in the PDA is described in FIGS, 

according to the present invention; 23-30, which illustrate exemplary screens displayed to a 

FIG. 5 is a block diagram of an exemplary PCI server PCI subscriber using a wireless PDA. 

according to the present invention; 65 K. Billing 

FIG. 6 is a block diagram of an exemplary embodiment of Billing procedures for a PCI network use is briefly 

a PCI database according to the present invention; described. 
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X. Conclusion received by a PCI database 44 and stored in a 

A glossary of acronyms used in this specification is profile" for that subscriber. This database controls the deliv- 

attached as Appendix A. ery of outgoing messages and the routing of incoming 

L PCI Overview messages and message notification. (In FIG. 2, wireline 

FIG. 1 is a simplified overview of a personal communi- 5 communications are indicated with solid line connections 

cations internetworking ("PCT) according to the present ^ wireless communications are indicated with dashed line 

invention. A consumer, an office for example, has various connections. The instructions to the PCI are shown with a 

messaging equipment, such as a voice mail system 20, an s ° Ud Une > ■» will be explained in greater detail below, 

e-nJlternoinal 22, fax machines 24, and telephones 26. the msfructions may be sent eilher by a wnreline or wireless 

These are all connected to wireline networks 29. For 10 ^ ^ MonBa&Qn 

example, toe e-man terminal 22 may be connected to a data aufllenticatm me subscriber ^ identity ^ vaUdating ^ 

packet network, such as Internet, whose packets are earned of subscribed t ^ s ' ubscriber > s ^Lge 

over phone hnes. The fax 24, phone 26, and voicemail deU ( inC oming messages) options and origination 

system 20 may be connected to a Public SwitchedTelephone (out g oin g messages) options and voice (telephone call and 

Network (PSTN), part of which belongs to a particular local 15 voice options. For origination, the subscriber may 

phone service company, and part of which belongs to a selert message distribution lists with specific media deUvery 

particular long distance service provider. options. The database 44 also supports access to the portions 

A mobile communications subscriber (for example an of the subscriber profile that the subscriber may control, 
employee who works at the office described above and The subscriber may use a personal telephone number to 
travels frequently) has various portable messaging 20 register at alternate wireline and wireless terminals while 
equipment, such as a PDA 30, a cellular phone 32, and a maintaining use of the message screening and delivery 
pager 34. These are connected to wireless networks 39. options selected and stored in a subscriber's profile. This is 
These wireless messaging options may be provided by called "personal mobility". Information about the location of 
different service providers. That is, the cellular phone may a wireless or wireline network location to which the sub- 
be connected to a wireless network of a cellular phone 25 scriber's terminal is connected automatically registers and 
service provider, the pager may be connected to a different deregisters a subscriber's terminal. This is called "terminal 
wireless network maintained by a pager service provider, mobility." 

and the PDA may be connected to a third wireless commu- FIG. 3 shows the PCI 40. The CPE (voice mail 20, e-mail 

nications network maintained by yet another service pro- 22, fax 24, and phone 26) are connected to wireline networks 

vider. 30 29. The mobile subscriber equipment (PDA 30, cellular 

A Personal Communications Internetworking ("PCT') 40 phone 32, and pager 34) are connected to wireless networks 

according to the present invention is connected between the 39. Both the wireline and wireless networks 29, 39 are 

wireless 39 and wireline networks 29. The PCI 40 permits connected to a PCI 40 at a service provider. The networks 

the mobile communications subscriber to send and receive 29, 39 are connected to a local exchange carrier (LEC) 42 for 

messages between disparate networks and messaging sys- 35 the personal communications internetworking, 

terns and a variety of service providers. The mobile com- A PCI database 44 is a physical communication system 

munications subscriber can receive e-mail, fax, pages, and which provides call processing functions for a collection of 

voice messages under a single phone number while using central office switches. The Pd database 44 includes the 

either a wireless or wireline network. The subscriber may mobile subscriber's profile, including message sending, 
also select the media format and serving network used to 40 message receiving, and service control options. The PCI 

receive messages. The subscriber may also select cross- database 44 may be a service control point (SCP) or a 

media notification of incoming messages, (i.e., the sub- network adjunct The PCI database may be connected via a 

scriber may receive notification from a pager message that service management system (SMS) interface to a service 

a voice mail message was received). integrator 46. The service integrator 46 allows the service 

The subscriber selects the wireline or wireless network 45 provider to update subscriber data and create and modify 

and media format to be used for delivering messages or subscriber profiles. 

notification of message receipt The PCI 40 will perform a The PCI database 44 preferably stores and updates the 

media conversion to allow, for instance, an e-mail message subscriber profiles. The profiles contain service related 

to be delivered to a fax server. The PCI 40 may also include information for mapping services to subscribers (eJg., 
accessibility controls which allow the user to screen mes- so screening, routing, terminal selection by subscriber selected 

sages by selected criteria such as media type (e.g.. e-mail, parameters, custom calling features, and the like); subscriber 

fax, etc.), message length (e.g., voice mail messages less authentication data (e.g., password and user ID.); user status 

than three minutes), or sender (e.g., only messages from the (registered or not registered); generic service profile for 

office and a certain client are to be forwarded). non-call associated service, such as subscriber address or 

For example, the subscriber may have notification of a 55 social security number; specific profile for a non-call service 
voice mail or fax message receipt directed to a wireless PDA (based on subscriber selected parameters); wireless data 
in the form of e-mail messages. If the subscriber's wireless providers identification (e.g., what cellular phone provider is 
PDA is not turned on or otherwise not operating, the used); and specific profile for call associated services (e.g., 
notification may be routed to an alternate wireless or wire- call forwarding), based on user selected parameters, 
line network. Notification to the subscriber that a voice mail 60 FIG. 4 is a more detailed depiction of the one node 43 of 
message was received may be, for example, rerouted to the the PCI. The PCI has a plurality of nodes and is preferably 
subscriber's pager, and notification that a fax has been built on the Advanced Intelligent Network (AfN) archi tec- 
received may be rerouted to the wireline e-mail. ture. Other network architectures may be used, but for 

FIG. 2 is a simplified version of the interconnections illustrative purposes, the description is directed to an AJN- 
between various messaging systems and a PCI. As shown in 65 based network. 

FIG. 2, a subscriber provides the network with message A PCI server 48 is a peripheral which performs messaging 

routing and delivery instructions. These instructions are and call redirection functions and interfaces with the PCI 
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database 44 to update the subscriber profile. The PCI server information. If the information is not local, the PCI server 48 

may be an AIN Intelligent Peripheral, such as a Bellcore will need to get the addressing information from another PCI 

Intelligent Services Peripheral, or a network adjunct. The server 48 at another PCI node or an interconnected private 

PCI server is connected to a switch 50. In the AIN directory serving agent which maintains a separate informa- 

architecture, this switch is a Service Switching Point Access 5 tion base. By using the existing standard, the PCI network 

Tandem (SSP AT), but may be any suitable switch, depend- and mail PCI servers message handling can independently 

ing on the architecture. The SSP AT 50 connects wireline manage the networks without interfering with the PCI 

networks to the CPE. The SSP AT 50 also connects the PCI service, 

server 48 with a central office (CO) 52. The SSP AT 50 also H The PCI Server 

connects to the SCP 44. The SCP 44 and the PCI server 48 10 The PCI server is a peripheral which performs messaging 

are directly connected. The LEC of FIG. 3 is part of a large and call redirection functions and interfaces with the service 

network and includes the PQ database 44, the PCI server 48, Control Point to update the subscriber profile. The PCI 

and the SSP AT 50. The PCI database may be connected to server performs a variety of functions. For example, an 

an SMS interface to a system integrator 46, as described illustrative PCI server: 

is an X.400 Gateway; 

routes messages using the X.400 messaging protocol; 



The PQ server 48 is also connected to various wireless 



and wireline networks 49 via signaling connections in these . , . 
networks to transmit and receive information for all of the connects proprietary messaging protocols into X.400 pro- 
messaging options. Illustratively, the PCI server provides tocol; 

access to Public Packet Switched Networks (PPSN), Public 20 interfaces with wireless data networks; 

Switched Telephone Network, (PSTN), Integrated Signaling interfaces with messaging systems; 

Digital Networks (ISDN), X.25 networks and TCP/IP net- interfaces with the PCI database to access subscriber 

works and may include access to asynchronous transfer profiles information- 

^rU^™?- SWitC D ^ d M ^ tim ^ abit Di § ital Service processes messages as specified by the user in the service 

(SMDS), and Frame Relay networks. 25 nrofile- 

The mobile subscriber may access his or her subscriber ' .. . . 

profile to change message sending, message receiving, and medla version such as text to fax or fax to 

service control options. These option changes are sent to the ex ' 

PCI database 44 to be stored in the subscriber profile FIG. provides access to an X.500 directory to determine 

4 shows, for example, a PDA 30 connected to the PCI server 30 addressing schemes for packet data; 

48 by a wireless network, but the subscriber may also use supports signaling between wireless data networks for 

wireline e-mail, or wireless or wireline telephones (using management functions such as registration; and 

DTMF signals) to access the subscriber profile. The mes- maintains a service profile cache, 

sages from the PDA, for example, are sent by a wireless FIG. 5 is a detailed illustration of a preferred embodiment 

network 54 to the PCI server 48 using, for example, an X.25 35 of a PCI server 48 according to the present invention. The 

transport. PCI server 48 includes three main elements: a call processor 

Delivering PCI service to a subscriber who may be 110, a data messaging peripheral 112, and a shared disk 

present on a number of different systems requires storage, memory 113. 

movement and caching of the service profile associated with The call processor 110 comprises a plurality of intercon- 

that subscriber. A mobility controller 49, located in the PCI 40 nected computers. The messaging peripheral 112 maybe 

server 48, is a controller and data store, which dynamically implemented by a computer such as a DEC XAP system, 

maintains service control information for a Message Trans- The call processor 110 includes a PCI applications server 

fer Agent (MTA). described below, in the Pd server 48, 114. The application server is the central decision making 

which connects the PCI server 48 to wireless data networks. point of the wireless messaging service described below in 

Data storage functions are handled by two tiered entities. 45 Section VI. Thus, the server 114 controls message routing, 

The subscriber profile is preferably located in the PCI screening, and notification for the wireless messaging ser- 

database 44 and is the top of the hierarchy where permanent vice. 

records such as service profile, authentication and validation The application server 114 is connected to a PDA protocol 
information, and the like of the subscriber or device are handler 115. The protocol handler is the interface to the 
maintained and performing status and location management so wireless network 54, for example the RAM wireless net- 
and mapping are performed. A service profile cache 51 is work This handles messages to be sent to and from the 
preferably located in the PCI server 48 and is a local cache subscribers PDA 30. A plurality of personal digital assistants 
entity which stores on a "needs basis" information such as (PDA) 30 are connected to the wireless network 54. 
service profiles and validation status and maintains a local The application server 114 also manages a PCI database 
repository for the service recipient It also administers 55 protocol handler 126. The protocol handler 126 is the 
information necessary to serve the wireless data network interface between the call processor 110 and the PCI data- 
entity, as well as sending updates to the permanent storage base 44. The application server 114 also manages a Service 
entity PCI database. The service profile cache 51 maintains Profile Cache (SPC) 51. The SPC 51 is maintained in the 
the personal data associated with the processing of the memory of the application server 114. The SPC 51 stores a 
mobility controller 49. The mobility controller 49 interacts 60 subset of the data in the subscriber profile stored in the POL 
with the PCI database-based subscriber profile (or third database 44. This subset is subscriber profile information 
party database) on behalf of the cache to obtain service which currently needs to be accessed frequently by the PCI 
profiles and location information related to wireless termi- server 48. 

nals. The SPC 51 stores and accesses data related to access 

PCI may also provide directory services as a value-added 65 systems such as wireless data providers and messaging 

component. The X.400 MTA can query a local directory services, and subscriber location. The SPC 51 may store and 

serving agent in the PCI server 48 for addressing and routing update data related to the subscriber location such as routing 



5,742,668 

9 10 

address for subscribers specific wireless terminals; store and The data messaging peripheral 112, which is optional, is 

updates services related data for a particular terminal type now discussed in greater detail. The data messaging periph- 

(such as uni- or bi-direction); maintain a list of the subscrib- eral is the gateway to the wireline electronic mail network, 

ers wireless data provides and message services; track the which network is designated 170, The data messaging 

subscribers terminal status (registered or not registered); 5 peripheral has a message transfer agent 158 for transferring 

provide a generic service profile for non-call messaging messages between the call processor 110 and the data 

service; and provide a specific profile for a non-call asso- networks 170, 54 either directly or through the PDA protocol 

dated service based on subscriber selected parameters. handler 115. The messaging peripheral 112 also includes a 

The application server 114 also manages the registration POP (post office protocol) server 190 and associated 

status of each application on each PDA 30 and controls 1Q memory 192 for providing a message storing capability. The 

customer profile information via each PDA 30. message directory 194 is used for storing a subset of service 

The call processor 110 also includes an IP Functions profile cache 51 relating to the routing of e-mail messages. 

Server 130. The IP Function Server 130 manages CallCom- The messaging peripheral 112 includes the message gate- 

mand applications. This server is also connected to the PCI wav 140. The message gateway 140 has the following 

database protocol handler 126 for communication with the capabilities: 

PQ database 44 and the PDA protocol handler 115 for 15 r , v T ^ ;f ,'-„„ ftw , DrT „„„!,„„,,•„„ „„,,„. -,, A • „,„ „ 

communication with the wireless network 54. The PCI \^° g t w !° Ration Tfr "l^w,, 

database protocol handler 126 handles both interfaces processor mat e-mail has arrived from the wireline 

between the PQ database and the PQ server, as described ^ network 170 for a subscriber. 

^l ow 2) Accept a request from the PQ application server 114 to 

Thus, the two main application servers in the call proces- 20 send an ^m*" 1 message to a wireline address, 

sor 110 are the IP Function server 130 for CallCommand 3) Accept a request from the application server 114 to 

applications and the PCI applications server 114 for wireless provide all unread messages stored in the server 190 

which would have been sent to a primary destination if 



The caU processor 110 also includes a plurality of com- the subscriber had been registered, 

munication interfaces. The protocol handlers 115 and 126 25 4) Accept a request from the application processor 114 to 

have already been discussed. The alphanumeric paging rewrite to the message store server 190 or back to the 

server (APS) 132 gives the call processor 110 the ability to sender. 

provide alphanumeric paging services. The APS 132 Using the call processor 110 and its associated 

includes one or more modems to communicate with terminal peripherals, a wide variety of services may be performed, 

equipment of a network 134 maintained by a paging service 30 These have been discussed above briefly. However, to 

provider. The APS communicates with the paging service understand how the call processor 110 operates to provide 

provider using, for example, the TAP protocol (Telocator these services, an exemplary description is provided. 

Alphanumeric Protocol). For example, when a wireline e-mail message arrives at 

The call processor 110 also includes a plurality of control the PQ server's Data Messaging Peripheral 112, the mes- 

processes which control peripheral equipment external to the 35 saging gateway 140 and messaging Controller 136 send 

call processor 110. These controllers are as follows: notification to the PCI application server 114 of the e-mail 

A message controller 112 controls the data messaging arrival. The PQ application server 114 will query the profile 

peripheral 136 and controls the sending of messages cache 51, or if necessary, the PQ database 44. Driven by 

between the call processor 110 and the data peripheral 112. data in the subscriber's profile, the PQ application server 

The mobility controller 49 comprises the PQ database 40 114 executes service logic to determine where to forward the 
protocol handler 126, the IP function server 130, the service e-mail (i.e., forward to PDA 30 or to POP server 190 
profile cache 51, and the PQ application server 114. The depending on screening outcome), and what media, if any, 
mobility manager provides control logic for user to use to send notification of the e-mail arrival, 
authentication, service request validation, location If a subscriber wishes to update me subscriber profile by 
management, user access to service profile, access 45 DTMF, the procedure is as follows. A call arrives at the PQ 
registration, and communication management such as rout- server 48. The switch controller 152 and transaction con- 
ing to user-specified destinations. The mobility controller 49 troller 150 forward the call to the IP functions server 130 
contains the service logic and handles service related pro- based on the dialed number. The IP functions server 130 
cessing for personal data and service access such as service sends a provide_instructions 1129+message to the PQ 
feature analysis; access system mapping relationship infor- 50 database 44 to determine how to handle the call. The PQ 
mation; identity management; subscriber validation and database 44 sends a request to play an announcement and 
authentication; billing information based on the subscriber; collect digits ("please enter PIN", collect PIN). The IP 
wireless data specific routing information for message deliv- functions server 130 returns the result of this request to the 
ery and subscriber paging; subscriber service validation; and PCI database 44. Again the PQ database 44 sends a request 
subscriber review and modification of the subscriber' s pro- 55 to the IP functions server 130 to play an announcement and 
file. collect digits ("voice menu", menu selection). The IP func- 

A transaction controller 150 controls a switch controller tions server 130 returns the result of this request to the PQ 

152 and a voice peripheral controller 154. The switch database 44. 

controller 152 controls the digital switch 156 which con- This process repeats as users are guided through menus 

nects to the public switched telephone network 58. The 60 and change profile elements. The PCI database 44 interprets 

voice peripheral controller 154 controls the voice peripher- the collected DTMF tones and updates the subscriber's 

als 160, which are for example text-to-speech converters. profile accordingly, 

The switch 156 and the voice peripheral 160 are also When a PDA 30 sends an e-mail message addressed to a 

connected by a Tl line 161. The digital switch 156 is wireline address the procedure is as follows. The PDA 30 

connected to the public switched telephone network by a 65 sends a UDP send_jnail message to the PQ application 

plurality of transmission media such as Tl lines 162. fax server 114. The PQ application server 114 detects the 

lines 163, and ADSI lines 164. message is not destined for another PQ subscriber and 
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forwards the request to the messaging controller 136, which 
forwards it to the messaging gateway 140 which is in the 
Data and Messaging Peripheral 112. The messaging gateway 
140 interfaces with the MTA 158 to send the e-mail to the 
wireline network 170 using, for example, the Simple Mes- 
saging Transfer Protocol (SMTP). 

The PQ server 48 may be based, for example, on either 
an X.400 MTA or an SMTP router and can convert between 
both protocols. The PQ server 48 may receive text messages 
from a variety of different text messaging systems such as 
Internet mail, third party messaging systems, or proprietary 
messaging systems. In the example where PCI routes mes- 
sages using an X.400 MTA, these messages must be con- 
verted to conform with X.400 protocol before they can be 
routed. Thus, an exemplary messaging gateway is an X.400 
gateway, which can be designed and built by a person of 
ordinary skill in the art 
HI. The PCI Database 

A PCI Database 44 maintains the subscriber profile, 
controls the CallCommand functions, and handles DTMF- 
based subscriber profile updates. 

The PCI database architecture shown in FIG. 6 comprises 
several application and support components. The application 
components include Multiple Services Application Platform 
(MSAP) 202; Service Provisioning and Creation Environ- 
ment (SPACE) 204; and Data and Report Subsystem (DRS) 
206. 

The service components include the Maintenance and 
Operation Console (MOC) 208; the Intelligence Peripheral 
Interface (IPI) 210; the Generic Data Interface (GDI) 212; 
the Service Network Interface (SNT) 214; and.the Data and 
Report database (D&R) 218. 

The service network interface (SNI) 214 provides a 
communication interface to external systems such as switch 
50 and PCI server 48. These interfaces include the IPI 21 0 
and GDI 212 which connect the PCI database to the PCI 
server via the TCP/IP network 213. The GDI 212 is used for 
uploading and downloading a subscriber profile to the PCI 
server 48. The IPI 210 is used for transmitting DTMF 
commands from a user via the PCI server 48. For 
redundancy, each intelligent peripheral interface (IPI) and 
generic data interface (GDI) processor preferably requires 
two logical connections to the PCI server. 

The Multiple Services Application Platform (MSAP) 202 
includes a call processor 220, a first call process request 
(CPR) database 222, an MSAP common 224, a shared 
memory 226. and a call contact database (CCDB) 228. The 
call processor 220 receives messages from and sends mes- 
sages to a message distributor 219 in the SNI 214. The 
message distributor determines whether the message 
received from the call processor 220 is to be sent to the IPI 
210 or the GDI 212. The call processor receives messages 
from the message distributor and sends them to the first CPR 
database, the CCDB 228, and/or the shared memory 226. 
The first CPR database 222 stores the subscriber profiles. 
The MSAP 224 connects the first CPR database 222 with the 
second CPR 230, which resides in SPACE 204. MSAP 
common 224 updates one of the CPR databases 222, 230 
when changes have been made to the other CPR database. 
The CCDB 228 is a temporary, dynamic storage for storing 
subscriber profiles, and related data during profile update 
procedures. The shared memory 226 allows different pro- 
cessors to use the same data. 

SPACE 204 is a service provider-operated module 
through which new PCI database applications are created 
and new subscriber profiles are initiated. SPACE 206 
includes the second CPR database 230 which contains the 
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identical information as the first CPR database 222 in MSAP 
202. When a new subscriber profile is to be created, a service 
provider uses a display terminal 232 in SPACE to provision 
a new service profile including certain subscriber informa- 

5 tion. The subscriber profile is activated through MSAP when 
the user initially registers. Service provider changes made to 
the second CPR database 230 are transmitted to the first CPR 
database 222 in MSAP via the MSAP common 224. 
Changes made to the second CPR database 230 by a service 

10 provider are not transmitted to the service profile cache 51 
in the PCI server 48 until a later time. That is, the PCI 
database 44 does not send data to the PCI server 48 unless 
requested by the server 48. The server profile cache 51 will 
be updated with this new information the next time the PCI 

15 server 48 requests a profile download, for instance when the 
subscriber next registers. SPACE 204 provides a function 
parallel to the Service Management System described 
above. 

The Data and Report Subsystem (DRS) 206 collects data 
20 about Ihe PCI database 44 usage which may be helpful to the 
service provider. For example, errors made by the subscriber 
when updating the user profile are noted. The types of 
alterations made, times such alterations are made, and the 
like are also stored for future use by the service provider. 
25 MOC 110 is a networkmaintenance support system which 
monitors the status of the network and checks for system 
failures and the like. 

When a subscriber wishes to update the subscriber profile 
using a PDA 30, the procedure is as follows. The PDA 40 
3b communicates with the PCI server 48. The PCI server 48 
sends a GetData message having a "Service Key", which is 
a preferably a ten digit PCI subscriber number (e.g., a 
telephone number), to the PCI database 44 over the GDI 
212. The GDI 212 translates the GetData message into a 
35 format understandable by the PCI database 44. The message 
is sent through the message distributor 219 and call proces- 
sor 220 to the first CPR database 222 where the subscriber 
profile resides. The Service Key is used to obtain the correct 
subscriber profile and the profile is sent through the call 
40 processor 220 to the message distributor 219o The message 
distributor determines that this message is to be sent to the 
PCI server 48 via the GDI 212. (The reason for this is 
discussed below.) The GDI 212 translates the data into a 
format suitable for the TCP/IP network and is transmitted to 
45 the PCI server 48. The requested changes are performed in 
the PCI server 48 and the updated profile is sent back to the 
PQ database 44 through the TCP/IP network, the GDI 21 2, 
message distributor 219, call processor 220 and to the first 
CPR database 222. The call processor 220 also sends a 
so message through the GDI 212 to the Pa server 48 which 
will be sent a wireless transmission to the PDA 30 acknowl- 
edging the subscriber profile update. The changes are also 
sent to the MSAP common 222 where they are sent to the 
second CPR database 230 in SPACE 204. 
55 During this process, information may be temporarily 
stored in the Call Contact Database (CCDB) 228. The 
CCDB database 228 provides temporary storage for sub- 
scriber profile updates that are suspended because they are 
waiting for action by a subscriber or waiting for data from 
60 an external system, such as the PQ server 48. During the 
time intervals between action by the user or delays in 
receiving data from an external system, the call processor 
220 stores the information in the CCDB database 228 and 
processes other calls. 
65 When a subscriber desires to update his or her subscriber 
profile using a touch tone phone, the procedure is as follows. 
The subscriber calls, for example, a service number pro- 



5,742,668 

13 14 

vided by the service provider. The call is routed to the PCI assigned for the PCI subscriber profile elements are pro- 
server 48. The PCI server 48 sends a message to the PCI vided in Appendix B. 

database 44 via the IPI 210 that the DTMF commands are Appendix B also shows the PCI profile data, including the 
present. The message is sent through the message distributor profile elements, their data types, maximum lengths, and 

219 to the call processor 220. The appropriate subscriber s GDI tag IDs. An * indicates elements which were shortened 
profile is retrieved from the first CPR database 222 in the to 3 2 bvtes because of GDI bvte limitations. The description 
MSAP 202 of ^ tv P es ^ lea Sf^ s of t^se elements is as follows: 

The call processor 220 instructs the PCI server 48 to play ^ BCD-encoded digits. The number N represents the 
a voice announcement instructing the caller to enter the maximum number of BCD digits, not octets, 

subscriber ID and password, by pressing the appropriate 10 cN Up to N ASCII characters. 

digits on the touch-tone phone. The information is entered cN Binary integer N bytes in i length, in network byte order 
by the caller, and the PCI database 44 validates this infor- (highest order bit transmitted first), 

mation. If the validation determines that the caller is an Because the portion of the PCI subscriber profile down- 
authorized subscriber, the PCI database 44 instructs the PCI loaded to the PCI server is large (preferably approximately 
server 48 to ask the subscriber to select which subscriber 15 ^000 bytes), and a maximum Transaction Capable Appli- 
profile information is to be modified. Currently, only two cation Program (TCAP) message size is 256 bytes, the 
fields are modifiable using DTMF messaging: changing a profile must be managed in segments. The service profile is 
wireline registration or recording a personalized greeting. divided into six segments as shown in Table 1. Each segment 
The subscriber selects either registering at a wireline phone is assigned a unique numeric identifier, 
or recording a personalized greeting. If wireline registration 20 

is selected, the PCI database 44 instructs the PCI server 48 ~~~~~ " 

to prompt a ten digit telephone number to which all incom- Pa Profile Segment segno* n> (decmal) 

ing calls will be routed. If the subscriber selects to record a Personal data l 

personalized greeting, the PCI database 44 instructs the PCI cc service profile 2 

server 48 to prompt me subscriber for a new greeting. 25 TZii ™itS screening 4 

If invalid information is entered at any time, the PCI e-mail from screening 5 

server 48 plays an error message to the subscriber and the \bice mail profile 6 

subscriber retries the modification. If the retry fails, the call — : 

is terminated f Otherwise, the subscriber's profUe is updated subscriber profile provides a subscriber's 

according to the modification, data synchronizing the mes- 30 ed ^ m and notiflcation . ^ 

sagesaresenttomePase^San^^ £ fe ^ ^ > 

instructs the PCI server 48 to inform the subscriber that the 6 . J ^ ^ 

PCI service profile was updated. ' 

The call processor 220 also sends a message through the Mediz ^ 

message distributor 219 to the GDI 212 and to the PCI server 35 

48 which updates the service profile cache 51 in the PCI Alphanumeric Pager A 

server 48. The changes stored back in the first CPR database p"^" 1 message stOTe | 

220 are sent to the MSAP common 224 where they are sent PDA P 
to the second CPR database 230. Note that DTMF function "Knee mail v 
signals, which use the 1129+protocol. are routed through the 40 wireline e-mail E 

IPI 210 and the subscriber profile data, which uses the GDI 

protocol, are routed through the GDI 212. 

IV. The PCI Server/Database Interface For example, if the. subscriber prefers to receive e-mail 

The interface between the PCI server 48 and the PCI which passes screening via the PDA 30, then the "primary 
database 44 is based on two protocols. The first protocol is 45 destination one" profile element will contain a "P". 
1129+. This protocol will be used to support the PCI FIG. 8 illustrates a message flow for profile retrieval using 
CallCommand feature and for subscriber initiated profile the GDI protocol. A subscriber attempts to register with the 
manipulation using DTMF. The second protocol is Generic PCI server either explicitly or implicitly (registration is 
Data Interface (GDI). The GDI is used for subscriber profile discussed in detail below). The PCI server 48 send a GDI 
management, specifically downloading a subscriber profile so GetData query to the PCI database 44 over one of the GDI 
from the PCI database 44 to the PCI server 48 and for links (line 260). The PCI server 48 may send one GetData 
applying updates to the profile stored in the PCI database 44. data query for each PCI profile segment. Each query will be 
FIG. 7 shows the logical links from the PCI database 44 processed by the PCI database 44 as an independent trans- 
to the PCI server 48. The PCI database 44 consists of a action with a unique TCAP transaction ID. Each GetData 
mated pair of PCI databases 44a, 44b, each containing three 55 query sent by the PCI server 48 will include a "Service Key" 
call processors 220 which each share the load. The links 250 parameter which is a ten-digit PCI subscriber number (e.g., 
are TCP/TP links between Intelligent Peripheral Interface a telephone number). This key should be used by the PCI 
(IPI) 210 and the Generic Data Interface (GDI) 212 proces- database 44 to identify the subscriber. In each GetData is a 
sors on the PCI database 44 to the PCI server call processor. list of tag IDs listed in the profile elements to be retrieved. 
Two logical connections are made from each IPI 210 and 60 The PCI database 44 responds to the GetData data query 
GDI 212 processors to the PCI server for redundancy. Thus, with a GetData response (line 262). The response contains a 
a full SCP configuration supporting PCI would preferably return code and data for each element requested in the 
require 24 logical links, as shown in FIG. 7. The PCI GetData data query. 

database initiates the opening of the logical links. FIG. 9 provides a message flow between the PCI server 48 

In this illustrative embodiment, the CallCommand feature 65 and the PCI database 44 for a profile update originating from 
employs the 1129-rprotocol. For the wireless messaging a wireless PDA 30. This wireless profile update uses the GDI 
feature, PCI uses the GDI protocol. The GDI tag IDs protocol. A subscriber performs a profile manipulation 
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activity, and the PDA 30 sends a profile data message to the subscriber starts the PCI application software on the PDA 30 
PCI server 48. The PCI server 48 sends a GDI SendData (this is called start-up registration) or when the subscriber 
query to the PCI database 44 over one of the GDI links (line clicks a status check button or one of the service registration 
264). The PCI server 48 may send one SendData query for request buttons on the PDA 30 either for the CallCommand 
each PCI profile segment for which a profile element was 5 or wireless messaging service. Once successfully registered, 
updated. Each query will be processed by the PCI database **" subscriber's profile is not already present in the service 
44 as an independent transaction with a unique TCAP profile cache 51 maintained by the PCI server 48, the PCI 
transaction ID server 48 will request a download of the subscriber s profile 

Each Send Data query sent by the PCI server 48 will *™ ** PC ] '■**?»* 44 * ^service Piffle cad« 51. The 
• i a «c„-„„ rrl » .1 . _„^-,.,u „u •„ ♦«» r*-r PCI server 48 sets the subscriber s registration status in the 
include a Service Key parameter which is the ten digit PCI 10 cache 51 10 ^ teh those requested by ^ e subscriber for me 
subscnber number. This key should be used by toe PCI wMfiSS service q for ^ ^ command service . 

database 44 to idenbfythe subscriber. Each SendData query mQ n one example of me mess flow 

contains a list of tag IDs provided in Appendix B and data between me PDA 30 and PCI server 48 during explicit 
for the profile elements to be updated. Not all tags in this registrat ion; This flow is also used by a subscriber to check 
segment may be included in the Send Data query; only those is registration of CallCommand or wireless messaging ser- 
profile elements which are actually updated by the sub- vices. A subscriber starts the PCI application software on the 
scriber will be sent The PCI database 44 should not update PDA or clicks the service status check, CallCommand 
data for which no tag was included in the SendData query. registration, or wireless messaging registration buttons on 

The PCI database 44 responds to the SendData query with the PDA. The PDA sends a registration request to the PCI 
a Send Data response (line 266). The response contains a 20 server 48 with the subscriber's validation information 
return code for each element requested in the SendData (subscriber ID and password) (line 300). The PDA 30 also 
query. starts a timer during which the PDA 30 will wait for a 

FIG. 10 is an illustrative example of one possible message response from the PCI server 48. The PCI server 48 server 
flow between the PCI server 48 and the PCI database 44 for receives the registration request and checks if the subscriber 
a DTMF profile manipulation message. The DTMF profile 25 is provisioned and if the subscriber ID and password are 
manipulator uses the 1129+protocol through the IPI 210. correct. The PCI server then sends a registration acknowl- 
The exact call flow for DTMF profile manipulation depends edgement (line 302). If the subscriber is not provisioned, no 
upon the implementation of service logic by the service service profile exists and the acknowledgement includes an 
designer, and upon options selected by the PCI subscriber. "unrecognized subscriber" response. If the subscriber ID 

As shown in this illustrative example, when a call arrives 30 and password are invalid, the acknowledgement includes an 
at the PCI server, the PCI server sends an 11294provide_ "incorrect password/PIN" response. Otherwise, the PCI 
instructions query to the PCI database (line 282). The called server acknowledgement includes a "success" response. If 
number contains a dialed number (i.e., the service number the PDA 30 does not receive an acknowledgement from the 
for a DTMF updates), while the ANI (automatic number PCI server within a predetermined time, it aborts the regis- 
identification) field contains the ANI, if any. The PCI DTMF 35 tration attempt and tells the subscriber to try again later, 
profile manipulations Call Process Request (CPR) is trig- Implicit registration automatically registers a subscriber 
gered by the dialed service number. The CPR 222 instructs for the wireless messaging service when the subscriber is 
the PCI server to play announcements and collect digits, currently not registered and wishes to send or fetch e-mail 
guiding the subscriber through voice menus and prompts from or to a PDA 30. Implicit registration is done as follows, 
(lines 284, 288). The PCI server responds to each request 40 The PCI server receives a fetch or send request from a 
with digits collected (lines 286, 290, 294). The CPR updates subscriber Who is not registered for the wireless messaging 
subscriber's profile with data collected via DTMF. service. The PCI server 48 retrieves a copy of the subscrib- 

V. PDA/PCI Interface er's service profile from the PCI database 44, if necessary, 

Communication between the PDA and PCI use, for and validates the subscriber's ID and password. The PCI 
example, an X.2S transport using the UDP IP protocol. A 45 server 48 validates the profile contents to make sure that 
brief discussion of the PDA structure is provided. The PDA subscriber may use the wireless messaging service. If wire- 
30 is preferably a notebook or palm top computer having a less messaging is permitted, the PCI server 48 processes the 
wireless network interface. The PDA may be, for example a request. Otherwise, It sends an acknowledgement indicating 
Hewlett Packard Omnibook 300 notebook computer running the reason why the subscriber is not permitted to use the 
a PCI application. FIG. 11 illustrates an exemplary PDA. 50 wireless messaging service. The message flow is the same as 
The PDA 30 has a central processing unit 295 connected to illustrated in FIG. 12. 

a bus B. The central processing unit ("CPU") 295 performs Once the subscriber is registered for either the CallCom- 
most of the computing and logic functions of the PDA 30. mand service or the wireless messaging service, the sub- 
A memory 296 is connected to the bus B, which stores scriber remains registered until the subscriber explicitly 
information to be provided to the CPU 295 or otherwise used 55 deregisters by either quitting the application or clicking the 
by the PDA 30. An input/output device 297, such as a deregistration button on the PDA 30. The subscriber can also 
keyboard, is also connected to the bus B which allows a user be implicitly deregistered for the wireless messaging service 
to input data for storage in memory 296 or for use by CPU by the PCI server 48 provided the PCI did not detect any 
295. A display 298 is connected to the bus B. The PDA 30 wireless messaging activities to or from that subscriber for 
also has a wireless communication interface 299 for com- 60 a given duration of time. Although the subscriber is 
munication with a wireless communication network. deregistered, the subscriber's service profile will remain in 

The PDA/PCI interface involves six types of message the service profile cache 51. The profile remains in the cache 
flow. These messages are: (l)registration/deregistration; (2) as long as the PCI server has some activity for the 
wireless messaging; (3) retrieving e-mail; (4) cross-media subscriber, such as incoming e-mail messages within a 
notification; (5) CallCommand; and (6) profile management 65 predetermined time, such as four hours. 

There are two types of registration and deregistration: No PDA-to-PCI server messages may be sent be the 
explicit and implicit. Explicit registration occurs when a PCI subscriber to implicitly register for CallCommand. thus, a 



5,74 

17 

subscriber should not be implicitly deregistered from this 
service. Implicit registration and deregistration occurs only 
for the wireless messaging service, and not for CallCom- 
mand. A subscriber remains registered for CallCommand as 
long as he or she is running the CallCommand software 
application on the PDA. 

Explicit deregistration occurs when a subscriber quits the 
PCI application software on the PDA (this is called exit 
deregistration) or when the subscriber clicks one of the 
service deregistration request buttons on the PDA for the 
CallCommand or wireless messaging services. FIG. 13 is an 
illustrative embodiment of a message flow between the PDA 
30 and PCI server 48 for explicit deregistration. A subscriber 
quits the PCI application software on the PDA or clicks a 
deregistration button on the PDA, The PDA 30 sends a 
deregistration request to the PCI server 48 with the sub- 
scriber's validation information (the subscriber ID and 
password) (line 304). The PDA 30 also starts a timer during 
which the PDA will wait for a response from the PCI server 
48. The PCI server 48 sends an acknowledgement (line 306). 
The PCI server 48 receives the deregistration request and 
checks if the subscriber ID and password are correct. If the 
subscriber ID and password are not correct, the acknowl- 
edgement includes an "incorrect password/PIN" response. 
Otherwise, the acknowledgement includes a "success" 
response. If the PDA 30 does not receive an acknowledge- 
ment from the PCI server 48 after a predetermined time, the 
PDA 30 assumes that it is out of radio coverage and informs 
the subscriber to retry later. 

Implicit deregistration occurs when the PCI does not 
detect any wireless messaging activity from or to the sub- 
scriber for a given duration of time, for example four hours. 
The PCI will also try to implicitly deregister a subscriber 
from the wireless messaging service in the middle of the 
night in the event that the subscriber inadvertently left the 
PDA 30 turned on. The PCI server 48 keeps a time-stamp of 
the most recent wireless messaging activity for each regis- 
tered subscriber in the subscriber's service profile main- 
tained in the service profile cache 51. Whenever the PCI 
server 48 detects any wireless messaging activities to or 
from a particular subscriber, the time-stamp is updated to the 
current time. The stored time-stamp of a registered sub- 
scriber is periodically compared to the current time. When a 
predetermined time elapses, the PCI server 48 assumes that 
the subscriber is out of radio coverage or has quit the PCI 
application. 

For implicit (or automatic) deregistration, the message 
flow is the same as illustrated in FIG. 13. The PCI server 48 
sends to the PDA 30 a deregistration request containing 
registration information about the subscriber. The PCI server 
48 also sets a timer during which it will wait for a response 
from the PDA 30. When the PDA 30 receives the deregis- 
tration request, it responds with registration acknowledge- 
ment which contains the registration information currently 
known to PDA. When the PCI server 48 receives the 
registration acknowledgement, it updates the subscriber's 
registration status based on information in the acknowledge- 
ment The PCI server 48 also updates the wireless messaging 
time-stamp associated with the subscriber to the current 
time. If the PCI server 48 does not receive an acknowledge- 
ment within a predetermined time as described above, the 
PCI server 48 assumes that the subscriber is no longer 
registered and removes all references to the subscriber from 
the service profile cache 51. 

Sending and receiving e-mail wireless messages involves 
two types of message flows: sending messages from the 
PDA 30 to the PCI server 48 and from the PCI server 48 to 
the PDA 30. 
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FIG. 14 is an illustrative example of a message flow 
sending an e-mail from a PDA 30 to a PCI server 48. When 
a subscriber sends an e-mail notification from the PDA 30, 
the PDA 30 forwards the e-mail notification to the PCI 

5 server 48. The body of the e-mail contains, for example, 
"to;from;subject;cc" information (line 308). The PCI server 
acknowledges this notification (line 310). If the e-mail is 
longer than can be transmitted in a single message, the PDA 
30 segments the e-mail into multiple, sequentially numbered 

to packets and sends them to the PCI server (lines 312, 316, 
320). Each packet sent from the PDA is responded to with 
an acknowledgement containing the reception status of the 
message and the sequence number it is acknowledging (lines 
314, 318, 322). The PDA 30 and PCI server 38 use the 

15 sequence number to maintain a sequential flow of packets. 
Out of sequence packets are discarded. Once all of the 
packets are received, the PCI server 48 puts them into their 
original order using the sequence number and forwards the 
now assembled e-mail to a message transfer agent, which 

20 then forwards the e-mail to its intended destination. 

The PDA 30 starts a timer each time it sends out an e-mail. 
If the PDA 30 does not receive an acknowledgement after a 
predetermined time (for example ten seconds), the send 
operation is aborted and the e-mail is stored in a local 

25 outbound queue for redelivery in the future. 

When an e-mail is being delivered from an PCI server 48 
to a PDA 30, a similar message flow is used. The only 
difference is that the PCI server 48 initiates the flow and 
sends the initial messages instead of the PDA 30. 

30 Retrieving e-mail involves two types of message flows: 
retrieving undelivered e-mail addressed to the PDA 30 and 
retrieving e-mail delivered a messaging system, such as a 
wireline e-mail system. When a subscriber is out of radio 
coverage or is not registered with PCI, the PCI sends e-mails 

35 addressed to be delivered to the PDA (PDA-bound e-mail) 
to an external mail storage system. The PCI server will also 
send certain e-mail directly to an external mail storage 
system (MS-bound e-mail), such as the subscriber' s wireline 
e-mail connected to his or her personal computer, according 

40 to the subscriber profile stored in the PCI database 

Aregistered subscriber can retrieve PDA 30 bound e-mail 
at any time by starting 'TETCH" operation. The PCI will 
send the PDA bound mail from the external mail storage and 
will also summarize MS-bound e-mail. 

45 An illustrative example of the message flow between the 
PDA and the PCI server for retrieving undelivered PDA 
bound e-mail is shown in FIGS. 15(a) and (b). If there are 
no MS-bound messages, an illustrative message flow is 
shown in FIG. 15(a). The PDA 30 sends a fetch request to 

50 the PCI server 48 (line 324) and starts a timer, which waits 
for an acknowledgement. If no acknowledgement is 
received within a predetermined time, for example twelve 
seconds, the PDA 30 assumes it is out of radio coverage and 
informs the subscriber to try again later. In response to the 

55 request, the PCI server 48 logs into an external mail storage 
system specified in the subscriber's profile. If any PDA- 
bound e-mail is stored in the external storage system, the 
PCI server 48 will (a) move the PDA bound e-mail from the 
external mail storage system into a pending to a in the PCI 

60 server; (b) send an acknowledgement to the PDA indicating 
the number of PDA bound e-mail now residing in the 
pending area; and (c) initiate delivery of these PDA bound 
e-mail from the pending area to the PDA (line 326). 
If there are MS-bound e-mail messages, an illustrative 

65 message flow is shown in FIG. 15(b). The PDA sends a fetch 
request (line 328) and starts a timer, Whenever the PCI 
server sends a summary message, it starts a timer. If the PCI 
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server 48 does not receive an acknowledgement within a profile download. The PDA 30 sends a download request to 

certain predetermined time, for example ten seconds, it will the PCI server and requests a copy of the subscriber's 

assume that the PDA 30 is out of radio coverage, abort the modifiable profile elements to be downloaded to the PDA 30 

send operation, and discard the summary information. In (line 360). The PCI validates the identity of the subscriber 

response to the request, the PCI server 48 will (a) send an 5 through its subscriber ID and password. If the subscriber's 

acknowledgement to the PDA indicating the number of identity is not validated, the PCI sends an acknowledgement 

MS-bound e-mail present (line 330); (b) extract summary and an error code and terminates the profile update session, 

information from those messages; and (c) send the summary If the subscriber's identity is validated, the PCI downloads 

to the subscriber' s PDA (line 332). When the PDA receives the subscriber' s modifiable profile elements (lines 362, 366, 

an acknowledgement from the PCI server, it informs the 10 370). Attached as Appendix C is a list of tags for modifiable 

subscriber based on the contents. profile elements. The PDA 30 acknowledges the received 

Summary information for the MS-bound e-mail is for- data (lines 364, 368, 372). The PDA starts a timer after 

matted into one ASCII text per e-mail and sent to the PDA. sending the download request. If the PDA does not receive 

If the summary information, or the number of summarized an acknowledgement or data from the PCI server within a 

e-mail require more than one message, the PCI server 48 is predetermined amount of time, for example, ten seconds, it 

splits the summary information into multiple, sequentially assumes that it is out of radio coverage and informs the 

numbered segments and sends each segment in a separate subscriber to try again later. The PCI server 48 starts a timer 

message (lines 336, 340). Each message from the PCI server each time it sends out data to the PDA 30. If the PCI server 

48 is responded to by the PQ server with an acknowledge- 48 does not receive an acknowledgement from the PDA 30 

ment containing the reception status of the message and the 20 within a predetermined time, for example ten seconds, it will 

sequence number it is acknowledging (lines 334, 338, 342). abort the profile download operation. 

Out of sequence messages are discarded. Once all of the Once the subscriber finishes editing the profile on the 

packets are received, the PDA 30 puts them into their PDA, a profile upload request is issued. An illustrative 

original order using the sequence number. example of the message flow between the PDA 30 and the 

Once the summary information describing the MS-bound 25 PCI server 48 for a profile upload is shown in FIGS. 18(a) 

e-mail messages is reviewed, the subscriber may start a and (p). After the subscriber issues a profile upload request, 

FETCH operation to retrieve these MS-bound e-mail mes- the PDA 30 sends an upload request to the PCI server 48 

sages. FIG. 16 is an illustrative example of a message flow requesting permission to send the updated profile elements 

between the PDA 30 and the PCI server 48 retrieving (step 374). The PCI server 48 validates the identity of the 

MS-bound e-mail. The subscriber selects an MS-bound 30 subscriber, for example by checking the subscriber ID and 

e-mail message to be received. The PDA 30 sends a retrieve password, and checks if there is an associated download 

request to the PCI server 48 containing the message selected request issued by the same subscriber. The check for an 

by the subscriber (line 344). The PCI server 48 responds associated previous download request is necessary so that 

with an acknowledgement (line 346), The PCI server 48 logs the PCI server 48 is sure that the profile the subscriber wants 

into the external message storing system specified in the 35 to change is the profile that the PCI server 48 has just sent 

subscriber's service profile and moves the MS-bound e-mail If the subscriber's identity is not validated, or there is no 

specified in the request out of the storage system into a associated download request packet, the PCI server sends an 

pending area in the PCI server 48. The PCI server 48 error code to the PDA 30 and terminates the profile update 

initiates a send operation which delivers the e-mail in the session. If the subscriber's identity is validated and there is 

same manner as discussed above, 40 an associated download request, the PCI server 48 honors 

Cross media notification (e.g., PDA notification of voice the request by sending an acknowledgement and a status 

mail message receipt) is sent to the PDA 30 using the same code of "OK" to the PDA 30 (line 376). When the PDA 30 

delivery as a wireless e-mail message to the subscriber. The receives the OK, it formats the updated profile elements and 

PCI server 48 originates the notification e-mail and the sends them to the PCI server 48 in the same way the profile 

e-mail subject is "message notification". The body of the 45 was sent to the PDA 30 during the download phase (lines 

notification e-mail contains the message sender's address 378-386). If no error is detected, the PCI server 48 sends the 

(i.e., the phone number for a voice mail), the date and time updated profile elements to the PCI database 44 to commit 

the message arrived at the PCI; the type of media, (i.e., voice the change. After a confirmation is received from the PCI 

mail, FAX, e-mail or other); whether the message is marked database 44, the PCI server 48 sends an acknowledgement 

urgent (if detectable); the length of the message (for 50 with status code of "OK" to the PDA to confirm and 

example, in minutes for a voice mail message); and, if conclude the profile update session (line 388), as shown in 

appropriate, the subject of the message. FIG. 18(a). 

Profile management allows the subscriber to modify wire- FIG. 18(£>) is an illustrative message flow when the PCI 

less messaging and CallCommand services by updating server 48 detects errors in an uploaded profile. The upload 

certain elements in the subscriber's service profile stored in 55 proceeds as above (lines 390-398). If the PCI server 48 

the PCI database 44 and the service profile cache 51 in the detects errors in the updated profile elements it responds 

PCI server 48. Profile information is not stored locally on a with an error message to notify the subscriber about the 

PDA 30. Updating the subscriber's profile using a PDA 30 invalid profile element (line 400). The PDA acknowledges 

always requires the subscriber to have a profile download receipt of the error message (line 402). The PCI server 48 

from the PCL 60 sends the invalid profile elements in a similar way as the 

Profile management involves two types of message flows, profile was sent to the PDA 30 during the download phase 

profile download and profile upload. FIG. 17 is an illustra- (lines 404, 406). 

tive example of the message flow between the PDA 30 and The PDA 30 starts a timer when its sends out an upload 

the PCI server 48 for a profile download. As indicated above, request or sends out data. If the PDA 30 does not receive an 

any profile change requires a profile download because the 65 acknowledgement from the PCI server 48 within a certain 

profile is never stored in the PDA 30. A subscriber starts a predetermined time, it will abort the profile upload operation 

profile management application on a PDA 30 and requests a and inform the subscriber to retry at a later time. 
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V. Wireless E-mail Messaging Services designate, for example, that if the wireless terminal is off, all 

PCI includes several wireless text message sending, text messages to be sent to e-mail and all voice messages are 

receiving, and service control features. PCI's wireless text to be sent to voice mail. 

messaging services are based on three network-based capa- The PCI service control features include supporting sub- 
bilities: 5 scriber profile management, supporting personal mobility 
message integration combining voice message across wireless and wireline networks, and supporting wire- 
notification, voice mail, telephone calls, e-mail, and less terminal mobility. A subscriber's profile may be updated 
fax- by sending text messages from a PDA over a wireless 
message routing and delivery, i.e., the PCI is a wireless or D™ (touch-tone) messages from either a 
a .-.„i-_„ „^,„„i, ,„ wireline or wireless terminal. The subscriber may program 
and wirekne network gateway, ,„ ^ {o ^ ^ fa ^ ^ ^ infor- 
subscnber profde, authenticaUon, sdect CT0SS for muugB notiflcation; se iect 



and validation. 



. . . . message screening and delivery options; select singL ,™~ 

The PCI uses personal communications service Integra- mailbox storage (for subscriber's with more than one voice 

tion capabilities to integrate the wireless service capabilities mailbox); and select a PCI service password. All of these 

available to the subscriber. This is accomplished by provid- 15 options may be maintained over wireless or wireline termi- 

ing the subscriber with control over the message routing and na js_ The subscriber may automatically register and dereg- 

delivery by the subscriber accessible "subscriber profile" ister a wireless terminal thus updating the subscriber's 

stored in the PCI. The subscriber profile contains subscriber profile to receive or reroute messages as preprogrammed in 

programmed instructions on message receipt, origination, the profile. 

and notification. Thus, PCI operates as a messaging gateway 20 The wireless data network provides data transport 
for providing access to multiple wireline and wireless between the PCI server 48 and the subscriber using a 
networks, while using subscriber profde information to wireless data terminal, such as a PDA 48. The wireless data 
control sending and receiving options. PCI allows wireless network may connect to the PCI server in a variety of ways, 
service providers to integrate the voice messaging, e-mail, using a variety of protocols. For example, the wireless data 
and fax message services for one subscriber through a single 25 ^twork may connect to the PCI using a leased line and run 
telephone number. Thus, one phone number may provide a a proprietary protocol to connect the PCI server via stan- 
singlelinkbetween the service provider and the subscriber's dardized protocols such as TCP/IP. 
voice and data communications lines. Text f essa ^g svstem ? 1x5 ^T* 
"~ . , . . ^ server through for example, Frame Relay, SMDS, ISDN, 
The message sending features include communications interface, orXr transport mechanism effective 
across disparate networks and broadcast communications. A 30 fof s ortin ^ communications may be used. An inter- 
subscriber may send voice mail, e-mail, and fax messages messj ^ e handling system wotocol< such as x . 40 0 (in which 
between different service providers and networks. A sub- ^ x 400 gateway conversion is needed), or Internet 
scriber may also send broadcast e-mail and fax messages, SMTP or other protocols supported by an interworMng unit 
which broadcasts may mix e-mail and fax messages within terminating the data transport interface, may be used to 
a single distribution list For example, the subscriber may 35 forward messages between the PCI server 48 and the system 
type a message on a PDA and send it to a distribution list accessing the PCL 

over a wireless network. The distribution list may, for The PCI server will preferably support sending and 

example, direct the PCI to deliver the message to the office receiving faxes in the T.434 format The PCI server may also 

as an e-mail and to a client as a fax. preferably support sending and receiving faxes using the 

The message receiving features include personal number 40 simple mail transfer protocol (SMTP) supported by the 

addressing, selection of message receipt media format, TCP/IP transport protocol. 

selection of cross-media message notification, and selection FIG. 19 shows an illustrative embodiment of a PCI 

of message screening and delivery options. A subscriber service which supports text messaging systems. In this 

may receive voice (e.g., phone), voice mail notification, example, a subscriber has a personal computer 402 at the 

e-mail, and fax communications under a single personal 45 office connected to a local area network (LAN) 414 and an 

telephone number. A subscriber may direct e-mail and fax enterprise text messaging system (for example, a local 

delivery based on selected parameters, such as time-of-day, network e-mail) 413, a personal computer at home 416, and 

day-of-week, etc. A subscriber's media message notification, a wireless terminal, such as PDA 30 that may send and 

voice mail notification of e-mail or fax messages, e-mail receive messages. All of these devices are connected to the 

notification of voice mail or fax messages, and fax notifi- 50 PCL For example, the subscriber's home personal computer 

cation of e-mail or voice mail messages may be delivered to 41 6 may be connected to the PCI 40 via a modem and a 

the subscriber based on selected options and parameters. wireline data network 418 over either a PSTN or ISDN. 

Alternatively, if the subscriber's wireless terminal is not Persons connected to the LAN may send text messages to 
activated, e-mail messages may be automatically routed to the subscriber by using the local text messaging system 
alternate destinations as defined by the subscriber's profile. 55 without using the PCI. That is, the user of computer 420 can 
For example, the subscriber may not want to receive all send an e-mail to the subscriber's office computer 412 
telephone calls at a visiting location to avoid unnecessary without entering the PCI node 40. Because the enterprise 
interruptions and unwanted incoming call charges. The text messaging system 413 is connected to PCL all enter- 
subscriber directs the PQ to send notification of phone calls prise messaging users may send messages to and receive 
to the pager and to route the call to voice mail Once notified, 60 messages from all PCI subscribers (including those not 
the user can determine from the phone number included in connected to the local text messaging system 413) by using 
the pager notification whether to call the person directly, an appropriate PCI address. 

check voice mail, or ignore the call until a later time. The A person connected to a different enterprise messaging 
subscriber may also direct which messages are to be routed system, such as a second text message handling system 422, 
to the subscriber's current serving network, which are to be 65 can send messages to the subscriber on the first message 
sent to another network, and what media is to be used to handling system 413 by routing the message through the PCI 
receive certain messages. The subscriber may also Server 48. 
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PCI subscribers are assigned a single personal telephone 
for both voice and data communication. For example, an 
E.164 address (i.e.. a telephone number) may be assigned to 
a PCI subscriber to use as the single PCI address. These 



If an e-mail message is to be delivered to an alphanumeric 
paging address, the PCI server translates the e-mail message 
into a paging message and sends the paging message to the 
paging network specified in the subscriber profile. The 



phone numbers may be geographically based according to 5 protocol between the PCI server and the paging network 



current PSTN architecture, but it is also possible 
portable universal numbers. Fifteen digit number formats 
may be desirable to permit sub-addressing. For example, a 
message destined for a PCI subscriber may be addressed to 
the subscriber's telephone number, e.g., 201-555-5555. If an 
originating mail system such as a LAN mail system or third 
party message handling system requires a domain identifier, 
the originator may have to specify 201-555-5555 @ PCI, or 
on the Internet 201-555-5555 @ pci.net. When the PCI 
server 48 receives the message, it will look at the subscrib- 



the Telocater Alphanumeric Protocol (TAP). The PCI server 
formats the paging message into a maximum page limit with 
a maximum number of characters per page. For example, the 
page limit may be two pages and a maximum of 256 
characters per page. The PCI server does not verify whether 
a paging message is actually delivered by the paging service 
provider. It will, however, verify that the message was 
successfully sent to the paging service provider. Because the 
PCI server does not provide this verification, it is assumed 
that messages sent to a pager arrive successfully at the pager. 



er's profile stored in the call process request database 222 15 If the subscriber profile contains an option for voice 
stored in a PCI database 44 to determine how to handle the message notification of e-mail messages, the PCI server 
mcorning message. An example of a few of the options that generates and sends a digitized prerecorded voice announce- 
PCI may provide for the subscriber are to: ment to the address specified in the subscriber service 

send the message to the subscriber's wireless PDA; profile. The protocol used to deliver the voice message 

send the message to the subscriber's wireline computer at 20 notification is the AMIS-Analog Protocol. 



send the message to the destination text messaging system 
at the office; 

send a notification of an incoming message to the wireless 
data terminal and the actual message to the text mes- 
saging system; 

send the message to any or all of the above; 

The subscriber may send text messages over the wireless 
data network or wireline data network to the PCI server 48. 
The PCI server 48 consults with the subscriber's profile at 
the PCI database 44 and forwards the message to the 
appropriate destination, depending on the routing destina- 
tion found in the profile. Text messaging systems not con- 
nected to the PCI 40 may send text messages to PCI 



In this illustrative embodiment, a preferred PCI server 
node functions as an X.400 message transport agent or 
SMTP router and routes messages destined for PCI sub- 
scribers and to those destined for users connected on other 
25 systems. In the case of an X.400 message transfer agent 
(MTA), X.400 addresses are used to internally represent 
subscriber addresses. The translation from the "user 
friendly" subscriber addresses such as E.164 numbering to 
the X.400 address would be done via a look-up table (ROM 
30 or other memory device) at the PCI access module or the 
X.400 gateway. Destination or source addresses from users 
on other networks are not converted to X.400 addresses, but 
are left in the native address format of the sending or 
receiving system. An X.400 gateway address may be added 



subscribers by using another network connected between the 35 t0 me message header, however, to allow PCI to route the 
sender' s text messaging system and the PCI subscriber' s text meS sage to an appropriate gateway. 

messaging system, for example, the non-connected text — — • -- • 

message may be connected to a PCI over the Internet 
The flow for wireless messaging is now described. 
The flow for a PCI subscriber receiving an e-mail mes- 
sage to a wireless PDA 30, for example, is as follows. An 
e-mail message is sent from a wireline or wireless sender to 
a PCI subscriber and arrives at the PCI server 48. The 
incoming e-mail contains a recipient address in the format of 
"201-555-5555 @ pci.net" where 201-555-5555 is the sub- 
scriber's ten-digit personal number and pci.net is the PCI 
server's domain name in the Internet. 

The PCI server 48 checks the subscriber's service profile, 
either from the profile service cache 51 in the PCI server or 
by downloading the subscriber profile from the PCI database 



The PCI server 48 is responsible for delivering a message 
to the subscriber listed in the destination field of the mes- 
sage. In a simple case, the subscriber has an X.400 or 

) Internet mailbox accessible to the PCI via one of its access 
connections. Alternatively, the subscriber profile may con- 
tain forwarding addresses which route the message for 
delivery to unusual destinations. For example, the subscrib- 
er's mailbox may reside on another message handling 

5 system, a wireless data network, wireline data network, or 
PSTN destination associated with a fax machine. The deliv- 
ery of such a message to a final destination is handled by an 
interworMng unit which is responsible for doing address 
translation and, if necessary, format translation as defined by 



44 into the cache 51 to determine how to process the e-mail 50 the subscriber profile entry, 
message. The profile contains screening and routing infor- For subject e-mail screening, the subject field is analyzed 
mation and cross media notification information. The PCI to determine if a match exists before comparing the address 
server 48 uses this information to send incoming email to an field. If the subject field matches an entry on the screening 
actual destination address that can be a wireless, wireline, or list, the treatment for a matched entry will occur. That 

paging address using, for instance, the UDP/IP protocol over 55 means, in this illustrative embodiment, that subject screen- 
wireless data network; the Internet SMTP protocol over the ing takes precedence over address sender screening. That is, 



Internet wireline network; or the Telocater Alpha Numeric 
Protocol (TAP), respectively. In this case, the subscriber has 
programmed into the subscriber profile to have the e-mail 
sent to a PDA 30. The PCI server 48 receives the e-mail 
message and forwards it to the wireless data network pro- 
grammed into the profile. The e-mail is transmitted over a 
wireless data network 39 for receipt by the PDA 30. 

If the e-mail cannot be delivered, the PCI server returns 
the e-mail to the original sender with a short description of 
why the delivery was unsuccessful, using the SMTP proto- 



if e-mail originated from an address that is excluded from 
the e-mail screening address list, the e-mail will still be 
delivered according to the screening criteria. 
) If the PDA 30 is not registered for the wireless messaging 
service or if the PDA 30 is out of radio coverage at the time 
the message arrives at the PCI server 48, the message will 
be sent to the subscriber's external message storage system, 
such as the text message system 413. 
5 VII. Message Flows 

PCI wireless messaging involves three types of message 
flow. The first is sending a message from one subscriber to 
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another, the second is receiving a message regardless of MTA for delivery 582, 584. Alternatively, the MTA may 
whether the subscriber is using a wireless or wireline directly deliver the message 586. 
terminal, and the third is sending a message to a non- VUI. The PDA Application 

subscriber. To better understand the capabilities of PCI and PDA/PCI 

FIG. 20 is an illustrative example of the message flow of 5 server interface, a discussion of the PDA user interface is 
a PCI wireless subscriber sending a message. The PCI user helpfuL The user interface is application software residing in 
submits a message 502. The message is received by a the PDA. This software is described by describing the 
message transfer agent in the PCI server. The MTA copies screens displayed on a PCI subscriber's PDA screen. The 
and temporarily stores the originating and destination following discussion is for an illustrative embodiment of the 
addresses 504. The MTA sends to the mobility manager 10 PDA user interface. A person skilled in the art recognizes 
function in the PCI server a request to validate the sending that the interface may be implemented in a myriad of ways, 
user as a PCI subscriber 506. The mobility manager sends FIG. 23 is an illustrative example of a PDA user interface 
this validation request to the PCI database and waits for a main menu. The menu allows the user to enter the CallCom- 
response 508. Upon receipt of an affirmative validation from mand or wireless messaging services, update the user 
the PCI database, the mobility manager sends the validation is profile, or check the status of the system by clicking on 
response to the MTA 510, 512. The MTA then sends the buttons 610, 612, 614, 616, respectively, 
mobility manager a request for the address of the user's FIG. 24 shows a computer screen after "status request" 
home MTA 514. The mobility manager routes this request to 616 is selected. The status request screen shows that there 
the PCI database 516. Upon receipt of a response from the are five local originating messages (waiting to be sent by the 
PCI database, the mobility manager routes the home MTA 20 PDA) and three outgoing messages (waiting to be retrieved) 
address to the MTA 518, 520. The MTA then routes the in boxes 618, 620, respectively. The various services' status 
message to the home MTA 522. If a third party PCI database is also displayed. As seen in FIG. 29, this subscriber's 
must be consulted, the home MTA request will be directed wireline registration is on, as seen in box 622. This registers 
from the PCI database to a third party PCI database 524, the subscriber on a particular wireline telephone, seen in box 
526. 25 624. This registration will direct calls to this phone number. 

FIG. 21 illustrates an example of the message flow of a The status request also advises this subscriber about the 
wireless PCI user receiving a message. When the PCI status of the CallCommand and wireless messaging features, 
receives a message from a subscriber, the MTA in the PCI as seen in boxes 626, 628. 

server copies and temporarily stores the destination address FIG. 25 is an illustrative example of a screen if the 
and the message 530. The MTA sends to the mobility 30 subscriber selected "Wireless Messaging" 512 on the main 
manager function in the PCI server a request for the PCI menu (FIG. 23). The subscriber will be connected to the 
subscriber's user profile 532. The mobility manager will wireless messaging service if "YES" 642 is clicked, 
retrieve this profile request from the PCI database 534. (If a FIG. 26 is an example of a screen which may appear if the 
third party PCI database is involved, the local PCI database subscriber selected "Profile" 614 from the main menu (FIG. 
contacts the third party PCI database through a switch 35 23). If the subscriber selects "Fax" 644 from this screen, a 
transfer point 536, 538.) Upon receipt of the subscriber's screen such as that shown in FIG. 27 may appear, which 
profile from the PCI database 540, the mobility manager allows the subscriber to enter a phone number into box 646 
requests the message from the MTA using a "message to which faxes will be directed. Turning on e-mail screening 
forward request" message 542. When the mobility manager activates both the subject and address screening. Subject 
receives the message from the MTA 544, the mobility 40 screening takes priority over address screening parameters, 
manager processes the message as indicated by the subscrib- If the subscriber selected "e-mail" 648 on the screen FIG. 
er's profile, which may involve media conversion or screen- 26, a screen such seen in FIG. 28 appears. The subscriber 
ing 546. After processing the message, the mobility manager can select where e-mail messages should be delivered 
sends the message to the MTA for delivery 548, 550. (destination screening) 650, where notification of e-mail 
Alternatively, the PCI server mobility manager function may 45 receipt should be delivered (notification screening) 652, 
directly deliver the message to the termination receiver 552. whether messages should be screened at all 654 and, if so, 

FIG. 22 illustrates an example of a message flow from a how they should be screened 656, 658. 
PCI wireless subscriber to a non-subscriber. When the MTA The destination 650 allows the subscriber to select des- 
receives a message from a PCI subscriber 560, the MTA tinations for incoming e-mail. Messages that satisfy the 
copies and temporarily stores the originating addresses and 50 screening requirement may be sent to two destinations 
the message 562. The MTA sends the mobility manager a (match A, match B). As shown in this illustrative example, 
request to validate the originating address as a PCI sub- e-mail received which match the subscriber's prepro- 
scriber 564. The mobility manager will send this validation grammed screening criteria are to be delivered only to a 
request to the PCI database and wait for a response 566. wireline e-mail, such as the subscriber's personal computer 
When the mobility manager receives an affirmative valida- 55 at the office, because match A 660 and match B 662 
tion response from the PCI database 568, the mobility designate the same destination. All received e-mail mes- 
manager sends the validation response to the MTA 570. sages which do not meet either criteria ("not matched") are 
Next, the mobility manager sends to the PCI database a sent to a selected fax machine 664, for example, the fax 
request for the PCI subscriber's profile 572. Upon receipt of machine at the subscriber' s office. 

the subscriber's profile from the PCI database 574, the 60 The subscriber also indicates where notification of a 
mobility manager requests the message from the MTA using received e-mail should be sent 652. Notification for all 
a "message forward request" 576. Upon receipt of the e-mail messages meeting the screening requirement should 
message from the MTA 578. the mobility manager processes be sent to a selected fax machine 666. The PCI network will 
the message as indicated by the user's profile, which may select information about the e-mail origination such as the 
require media conversion or obtaining the addresses for the 65 author, recipient, and subject matter and convert it to a 
distribution list for the message 580. After processing the facsimile format and send the message to a fax machine, 
message, the mobility manager sends the message to the Notification of all e-mail that does not meet the screening 
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criteria are sent to a pager 668. The PCI network will take 
the originating message information and turn it into alpha- 
numeric information according to the TAP protocol and send - 
it to the subscriber' s pager. If the screening option is turned _ 
off. notification of all incoming e-mail is sent to voicemail 5 
670. The PCI network will convert the origination informa- 
tion from text to synthesized speech and send the informa- 
tion to a selected voice mailbox. 

The user may also select whether to screen incoming 
e-mail messages at all 654. If the screening is on, the user 10 
may screen e-mail based on the originating address 656 or 
subject matter 658. 

FIG. 29 is an illustrative screen which the subscriber may 
use to edit e-mail screening according to address by clicking 
box 656 (FIG. 28). The subscriber may input new e-mail 15 
addressees into box 672 and add them to a list by clicking 
a box 674 or select addresses already entered to be included 
in a screening criteria as seen in box 676. For example, the 
user may want e-mail messages originating from the fol- 
lowing addresses to be routed according to the screening 20 
criteria: cclstanp, cclrizzo, and cclrupin. E-mail messages 
originating from these addresses will be routed and notified 
according to the criteria selected on the screen illustrated in 
FIG. 28. 

If the user selected to edit the "subject" a screening 25 
criteria based on "subjects" by clicking box 658 (FIG. 28), 
a screen such as that illustrated in FIG. 30 is presented. The 
user may type in to boxes 678 particular subjects which 
should be routed according to a screening criteria. The 
subject will search the incoming e-mail origination infor- 30 
mation to determine the subject of the e-mail. Subjects may 
include "urgent", "personal", the name of a client or project, 

K. Billing 

Billing operations is supported by an Automatic Message 35 
Accounting Network Function. The automatic network 
accounting measures, collects, formats and outputs network 
usage information to upstream billing and other operation 
application and service purposes. Preferably, automatic mes- 
sage accounting data is collected at various stages of service 40 
flows across network equipment and services. 
X. Conclusion 

An improved e-mail system is described with provides 
enhanced delivery and notification options and profile 4J 
update capabilities. 

While the invention has been described by the reference 
to specific embodiments, this was for purposes of illustration 
only and should not be construed to limit the spirit or the 
scope of the invention. 50 
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Glossary of Acronyms 



APPENDIX 1-continued 



Glossary of Acronyms 



MOC 
MSAP 
MIA 



intelligent peripheral interface 
integrated signaling digital networks 
local exchange carrier 
maintenance and operation console 
multiple services application platform 
message transfer agent 



personal digital assistant 

post office protocol 

public packet switched network 

public switched telephone network 

switched mulmnegabit digital service 




Personal Data (1) 



Subscriber ID Number 



V-Mail System Phone Number 
V-Mail System Mailbox Number 
Paging Terminal Phone Number 
Paging PIN 

Mail Storage Account ID 
Mail Storage Password 
Wireless Provider Subscriber ID 
Wireless Voice Phone Number 



Call Command Registration Status 



Secondary Destination 



E-Mail Subject Screening (4) 



E-Mail Screening Status 



D&R 
DRS 
DTMF 



call process request . 
data and report database 
data and report subdivision 
dual tone multiple frequency 
generic data interface 
home location register 
intelligent peripheral 



E-Mail From Screening (5) 



E-Mail & 
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APPENDIX 2-continued 



Voice Mail Profile (6) 



Secondary Notification 
Default Destination 
Default Notification 



Tag Description 



Password for subscriber registration 

Password for retrieval of messages from message store 

FAX Machine Number 

Call Command Status flag (1 = ON and 0 = OFF) 
■Wireline Registration Number for remofc 

ining status flag (1 = ON and 0 = OFF) 



006 



007-021 E-mai 

022-026 E-mail "Subject" screening 1 through 5 

027 E-mail Destination A - Screening Criteria Match 

028 E-mail Destination B - Screening Criteria Match 

029 E-mail Notification - Screening Criteria Match 

030 E-mail Destination - Screening Criteria Not Match 

031 E-mail Notification - Screening Criteria Not Match 

032 E-mail Notification - Screening OFF 

033 Voice-mail Screening Status Flag (1 = ON and 0 = OFF) 
034-038 Voice-mail "From" Screening 1 through 5 

039 Voice-mail "Urgent" Flag (1 = ON and 0 = OFF) 

040 Voice-mail Notification - Screening Criteria Match 

041 Voice-mail Notification - Screening Criteria Not Match 

042 Voice-mail N< " " ' 



1. A communication system comprising 45 
a plurality of wireless subscribers each having a single 
address to which electronic mail messages and fax, 
pages, and voice communications may be sent; 
means for storing a profile for each wireless subscriber, 
said profile containing for each of said wireless sub- 50 
scribers for (1) screening information for selectively 
screening incoming messages based on at least one of 
message origin, time of day, and day of week; (2) 
routing information for transmitting the message to the 
subscriber or for returning the electronic message to the 55 
sender with a short description of why delivery was 
unsuccessful: (3) and cross-media notification informa- 
tion for translating the electronic message into a paging 
message to be sent to a paging network and for sending 
a voice message notification of the electronic mail 60 
message; and 

means for receiving an electronic mail message addressed 
to one of said subscribers and responsive to the infor- 



mation in said profile for said one subscriber for 
causing one of (1) delivering the electronic mail mes- 
sage to said one subscriber; (2) returning the electronic 
mail message to its sender with a short description of 
why delivery was unsuccessful if the electronic mail 
message cannot be delivered to said one subscriber; (3) 
translating the electronic mail message to a paging 
message and delivering the paging message to a paging 
network if the electronic mail message is to be deliv- 
ered to a paging address; and (4) sending a voice 
announcement to the address specified in said one 
subscriber's profile. 

2. A method for receiving an electronic mail message 
from a sender addressed to a wireless terminal at the same 
telephone number to which fax, pages, and voice commu- 
nications may be sent, said method comprising the steps of: 

determining from a pre-stored profile for the user how to 
process the electronic mail message, the profile con- 
taining (1) screening information for selectively 
screening incoming messages based on at least one of 
message origin, time of day, and day of week; (2) 
routing information for transmitting the message to the 
user or for returning the electronic message to the 
sender with a short description of why delivery was 
unsuccessful; (3) and cross-media notification informa- 
tion for translating the electronic mail message into a 
paging message to be sent to a paging network and for 
sending a voice message notification of the electronic 
mail message; 

and, responsive to said determining step, causing the 
message to be delivered to a forwarding address dif- 
ferent from the address of the user' s wireless terminal. 

3. The method for receiving an electronic mail message 
from a sender addressed to a wireless terminal at the same 
telephone number to which fax, pages, and voice commu- 
nications may be sent, said method comprising the steps of: 

determining from a pre-stored profile for the user how to 
process the electronic mail message, the profile con- 
taining (1) screening information for selectively 
screening incoming messages based on at least one of 
message origin, time of day, and day of week; (2) 
routing information for transmitting the message to the 
user or for returning the electronic message to the 
sender with a short description of why delivery was 
unsuccessful; (3) and cross-media notification informa- 
tion for translating the electronic mail message into a 
paging message to be sent to a paging network and for 
sending a voice message notification of the electronic 



said determining step further comprising consulting a 
distribution list containing a plurality of delivery 
destinations, each destination having a delivery format 
of one of a facsimile and an electronic mail format, and 

responsive to said determining step causing the message 
to be delivered to the plurality of destinations from the 
distribution list, the message being routed to each 
destination in the delivery format prescribed by 1he 
distribution list 
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type of tasks the user requests, etc.). Moreover, because 
DATABASE USAGE METERING AND the database never leaves the central computer (each 

PROTECTION SYSTEM AND METHOD user is typically given access to only small portions of 

the database at a time), there is no danger of someone 

This is a division of application Ser. No. 06/918,109, 5 making unauthorized copies of the database, 
filed Oct. 14, 1986, now U.S. Pat. No. 4,827,508. However, centralized databases have important dis- 

The present invention relates to regulating usage of a advantages. For example, it takes a relatively long time 
computer database. More particularly, the invention to manipulate information in a centralized database due 
relates to techniques for preventing unauthorized use of to the relatively slow data transmission rates of standard 
an electronic digital information database and for mea- 10 communications channels and because the centralized 
swing the utilization of the database by authorized us- database computer typically shares its resources among 
ers- hundred or thousands of users at once. This can be a 

Information conveyed in electronic form is rapidly serious drawback if the user wishes to access a large 
becoming the most valuable of commodities. Electronic volume of information or wishes to perform particu- 
digital databases now exist for a variety of different 15 larly complex data manipulation tasks. Also, it may take 
applications and fields of endeavor, and many busi- a long time during periods of peak database usage be- 
nesses presently rely heavily on their ability to access fore communication can be successfully established 
those databases. with a centralized database computer, decreasing the 

The value of being able to instantaneously, electroni- utilization of the database and causing some users to 
cally access important, accurate information cannot be 20 become frustrated. Further disadvantages include the 
overestimated. Many of our daily activities depend on expense of establishing long-distance communications 
our ability to obtain pertinent information in a timely paths (e.g., WATS telephone line maintenance charges, 
fashion. While printed publications and electronic mass long-distance direct-dial telephone charges, satellite 
media together fulfill most of the average person's in- channel costs, etc.) between distant user terminals and 
formational needs and most often are the only source 25 the central database computer, and the reliability prob- 
for full-text reference information, just about any effort lems associated with such communications paths. More- 
to access information can benefit from the vast informa- over, the centralized computer facility needed to handle 
tion handling capabilities of the computer. In today's the access requests of many distant users simultaneously 
fast-paced world, we quickly come to insist on and rely is extremely expensive to purchase and maintain, 
upon the most thorough and up-to-the-minute informa- 30 With the advent of cheaper computer hardware and 
tion available — often made possible only by electronic new, high density information storage devices (such as 
data processing and informational management technol- the optical disk and the bubble memory), it has become 
ogy. On-line, public databases, now a two billion dollar practical to give users their own copies of large and 
a year industry, are a case in point. complex databases and permit users to access and ma- 

As the "information explosion" continues its course, 35 nipulate the databases using their own computer equip- 
more and more people will become dependent on elec- ment Optical disks are capable of storing vast amounts 
tronically-stored information and people will continue of information at relatively low cost, are small enough 
to be willing to pay premium prices (when necessary) to be sent through the mails, and can provide data at 
for access to and use of such information because of its extremely rapid rates. Bubble memory devices provide 
usefulness and value to them. Currently, the principal 40 some similar capabilities. 

resource for large, electronic information data bases are CD and related digital disk drives can currently store 
on-line (public) data base services such as Dialog Infor- up to 225,000 pages of full-text information per remov- 
mation Services, Mead Data Central, Dow Jones Infor- able diskette and can inexpensively maintain, in excess of 
mation Services, Source, Compuserve, and many oth- 1,800,000 pages of text simultaneously on-line. These 
ers. Most on-line data bases are abstract and/or biblio- 45 technologies are ideal for personal computer informa- 
graphic in content, and many are used primarily to tion base libraries. CD drives use removable compact 
access the document locations of specified information, disks (essentially identical to an audio compact disk) the 
rather than for the recall of the original document full- very low cost and enormous storage capacity has been 
text. predicted to result in an installed base of as large as one 

Historically, personal computers have been used pri- 50 million drives to 10 million drives (including non-CD 
marily for word-processing, modeling, and, to a lesser but related optical storage technology) by the end of 
extent, the structured data base management of records. 1990. Owners of "CD-ROM" and related drives will 
Technology that enables theuser of, for example, a per- create an enormous demand for both lexical software 
sonal computer to search for, locate, and retrieve topi- and electronically published information base products, 
cally related full-text information from vast full-text 55 Mitsubishi Research Institute of Japan, for example, 
data bases would be extremely useful and valuable. estimates that between 8,000 and 12,000 different CD- 

The only viable way to make some kinds of informa- ROM publication titles will be on the market by the end 
tion (e.g., information which must be constantly up- of 1990. 

dated) available is to maintain centralized databases and Hence, it is now possible to store some databases on 
permit users to access the centralized databases through 60 transportable, high-density information storage devices, 
telephone lines or other communication means. Until and simply mail each user his own copy of the data- 
very recently, this method has been the most cost-effec- bases. The user can in this way be given exclusive ac- 
tive way to offer access to electronic databases. Access cess, via his own computer system, to local, on-site 
to a centralized database can be controlled relatively databases. Rapid access time is provided because access 
easily, and users c n be charged for using a centralized 65 to the databases is exclusive rather than shared, and 
database in accordance with parameters which are rela- because data can be read from the database storage 
tivelY easy to measure (i.e., the amount of time the user device by local high-speed I/O devices and transmitted 
is connected to the database computer, the number and over local high-speed I/O channels or networks. The 
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stored databases can be updated periodically if neces- various portions of a data base only to those indi- 

sary by sending the user storage devices containing a viduals possessing the proper security code(s); and 

new version of (or new portions of) the databases. Ascertaining the degree of usage of the information 

It is very expensive to build a database. One way to base. The present invention stores, in one of several 

recover the costs of constructing and maintaining a 5 alternative forms of non-volatile memory, the dates 

database ("Return On Investment", or ROI) is to and times that any files (or documents, sections, 

charge a flat subscription or access fee to each user properties, etc.) are accessed and also records the 

subscribing to use the database. If this is the only billing amount of information read from each file into 

method used, however, infrequent users of the database memory by the user. 

may be discouraged from subscribing, because they 10 With the present invention, a CD-ROM disk, for 
would be asked to pay the same cost a frequent user example, might contain all issues of 10 separate publica- 
pays. Thus, many database owners charge subscribers a tions (technical, medical, business, etc.) going back for 
nominal subscription fee, and then periodically (e.g., five years. Each publisher would be able to set the price 
monthly) charge users a fee calculated in accordance for the use of its publication or publications and each 
with the amount the user has used the database. 15 publisher could then receive a "copyright royalty" 
While it is easy to measure the amount someone uses return-on-investment based on the actual customer 
a centralized database (e.g., simply time each access usage of the publishers' products. Therefore, publishers 
session length and store the time information with user contributing more important, popular or costly to de- 
identification information), there is no convenient way velop lexical information base properties could earn 
to measure the usage of a database residing on a user's 20 revenues commensurate with the market demands and 
own computer, or to convey such usage information to pricing strategies for their products, 
the owner of the database. Techniques are known for The present invention eliminates the necessity of 
automatically, electronically measuring consumption of determining how much of the net revenue of a CD 
a commodity such as electricity, water or gas, storing information base product each contributing publisher 
the measurements in a memory device, and periodically 25 should receive (currently an issue of considerable con- 
downloading the stored measurements over a telephone cern to publishers). The present invention also ensures 
line to a central billing computer. Unfortunately, these the data security of information bases — a critical, fre- 
known techniques are not readily adaptable to database quently voiced, and previously unanswered problem 
usage metering, and moreover, are neither secure causing considerable publisher anxiety. It would be 
enough nor provide the security against database piracy 30 quite difficult (requiring a high level of specialized ex- 
that most database owners demand. pertise and costly high-powered computers) to "break" 
The prevention of unauthorized database usage be- the hardware/software data security system provided 
comes a huge problem whenever a stored database by the present invention and copy material without 
leaves the possession and control of the database owner. being charged an appropriate fee. 
Computer program manufacturers lose millions of dol- 35 Publishers can license their products at an exception- 
lars each year to "pirates" who make unauthorized ally low initial cost to customers (i.e. for a $25.00 initial 
copies of software and distribute those copies for profit. fee instead of a $ 1,000.00 or more annual fee). Low 
Complex databases are often even more expensive to initial licensing fees would result from the usage audit- 
produce than programs, so that potential contributors ing capability of the present invention and would allow 
of data base properties, as well as database owners 40 new clients to experiment with the product at little or 
themselves, may be extremely hesitant to permit elec- no risk. Similarly, customers who anticipate a low level 
tronic copies of their properties or databases to leave usage of a given information base product may find the 
their control copies will be made. The copyright laws lower costs of a usage based fee schedule a practical and 
and contractual licensing agreements may deter, but affordable justification to acquire a product that would 
will not prevent, unauthorized use and copying of data- 45 otherwise not be purchased, 
base. In sum, the present invention will: 

SUMMARY OF THF ttmvftvjtton L Significan^Y accelerate market penetration of elec- 

SUMMARY OF THE INVENTION ironically published products due to substantially lower 

The present invention provides a database access initial license costs; 

system and method at a user site which permits autho- 50 2. Greatly enhance the ultimate market penetration of 

rized users to access and use the database and absolutely CD published products by making CD publications 

prevents unauthorized database use and copying. The affordable to a much larger body of customers; and 

present invention also provides a facility for measuring 3. Produce higher ultimate revenues per published 

usage of the on-site database for the purpose of billing disk from those customers who would otherwise have 

the user according to the amount he has used the data- 55 purchased a costlier version of the database product, 

base, and for periodically conveying the measured The security protection provided by the present in- 

usage information to the database owner (or his agent) vention will give publishers significant advantages in 

— while preventing the user from tampering with the securing exclusive contracts for important publishing 

measured usage information. information base properties, since the invention pro- 
The invention solves fundamental media based elec- 60 vides the information base property contributors with: 

tronic publishing issues including: 1. Vastly superior copy protection security; 

• Security of the information base. The present inven- 2. Ultimately greater revenue; 

tion provides a code/decode Interlock System 3. Publisher specific control over pricing; and 

which includes both software and a tamper proof 4. A return-on-investment commensurate with the 

hardware module that prevents unauthorized and- 65 market demand for their information base property, 

/or unmetered use of a protected information base. In accordance with one important feature of the pres- 

The present invention also supports a multi-level ent invention, a storage medium stores the database in 

coded security access system limiting access to encrypted form, and also stores index information 
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which correlates portions of the encrypted database 
with index keys. The index information may itself be 
encrypted if desired. A host digital signal processor 
operatively connected to the storage medium is prepro- 
gramed so as to generate a database access request, read 5 
the index information from the storage medium, identify 
(in accordance with the index information) the portions 
of the encrypted database which satisfy the access re- 
quest, and read the identified encrypted database por- 
tions from the storage medium. 10 

A secure decoder control logic device coupled to the 
host processor receives the encrypted database portions 
read by the host processor, decrypts portions of the 
encrypted database read by the host processor to pro- 
duce corresponding decrypted information, and trans- 15 
mits the decrypted information back to the host proces- 
sor. The decoder control logic device also measures the 
quantity of usage of and/or other parameters pertaining 
to the information decrypted by the decrypting device, 
and stores these measurements in a non-volatile (and in 20 
many cases tamperproof) memory device. The inven- 
tion thus provides a detailed record of database usage — 
including a breakdown of usage of each file or "prop- 
erty" stored on a local storage medium. Additional 
decryption of database information can be prevented or 25 
disabled if more than a certain percentage of a database 
(or more than a specified contiguous portion of a data- 
base) has been copied by the user as an additional safe- 
guard preventing unauthorized copying. 

The system may further include means for preventing 30 
tampering with the memory device and/or the decoder 
control logic means. 

In accordance with another important feature of the 
present invention, database usage information is stored 
at a user's site and is periodically communicated to a 35 
central billing facility. For example, the non-volatile 
memory device storing data indicating database usage 
may be housed in a replaceable module. Periodically, 
the user disconnects the module from his computer 
system and sends it to a centralized billing facility. At 40 
the centralized billing facility, the contents of the mem- 
ory device are read and used to bill the user according 
to his database usage. 

In accordance with yet another important aspect of 
the present invention, communications is periodically 45 
established between the user's site and a central facility 
for the purpose of telecommunicating database usage 
information stored at the user's site to the central facil- 
ity- 

In accordance with yet another important feature of 50 
the invention; the user is automatically prevented from 
decrypting the encrypted database after a predeter- 
mined event occurs (e.g., "expiration" of a memory 
module, or excessive database usage indicating copying 
attempts) unless the user has implemented an "antidote" 55 
(e.g., input secret information into his computer system 
and/or install a replacement component). 

Because the database is stored in encrypted form 
(and/or the database directory is encrypted or other- 
wise coded), the only way to obtain useful database 60 
information is to decrypt portions of it using the tamper- 
proof decrypting means of the invention. Safeguards 
may thus be used to prevent unauthorized database 
decryption. 

Thus, the present invention resolves several funda- 65 
mental problems that would otherwise impede the rate 
of growth of the CD-ROM and CDI electronic publish- 
ing markets. For example, it is a costly process to create 
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the core properties that may be incorporated into an 
information data base, and the structuring of the data 
base itself may, in some circumstances, be a costly ef- 
fort. One way for data base preparers to recover the 
costs of constructing and maintaining a database is to 
charge a flat subscription or access fee to each user 
subscribing to use the database. If this is the only billing 
method used, however, infrequent users of the database 
may be discouraged from subscribing — because they 
would be asked to pay the same cost a frequent user 
pays. Furthermore, potential users may be hesitant to 
pay a significant one time or initial fee to acquire a 
technology or product with which they are unfamiliar. 

With the present invention, a user will be able to pay 
(if so structured by the data base provider) according to 
his usage of the product and both the perceived risk, as 
well as — in lower usage environments — the high cost 
of the use of the technology, can be reduced or elimi- 
nated. Furthermore, since the present invention should 
accelerate the installed base and revenue growth rate 
for a given product, it may enable costs for even the 
high volume users to drop as well. 

Moreover, database use can be measured simply by 
measuring the quantity of information which is de- 
crypted. Other parameters relating to database usage 
(e.g., which databases and/or database subdivisions 
have been used; and the time, date and duration of use of 
each database and/or subdivision) may also be moni- 
tored and stored. The stored usage information can be 
periodically communicated to a centralized facility for 
billing the user in accordance with his database usage. 
Moreover, the user's on-site database access system can 
be designed to cease functioning unless the user installs 
a new component and/or inputs "secret" information — 
and the centralized facility can provide the user with 
such replacement components and/or secret informa- 
tion only when the user has paid his bill. 

Because the invention provides a detailed record of 
which literary properties have been used and how much 
each property has been used, use payments paid by the 
user may be fairly apportioned to the property owners 
according to actual use of their respective properties. 
For example, if a user licenses a storage medium storing 
a library containing hundreds of different literary prop- 
erties and then uses only two properties in the library, 
the owners of those two properties can be paid substan- 
tially all of the licensing fees charged to the user. 

A free market system is thus maintained in an envi- 
ronment not otherwise susceptible to free market com- 
petition. Publishers and authors can beassured that they 
will receive incomes based on customer demand for 
their properties, and publishers can retain absolute con- 
trol over pricing — despite the fact that the properties 
are being distributed on a storage medium along with 
hundreds of other properties. "Best sellers" can still be 
distinguished from unpopular works, and authors can be 
paid royalties based on consumer demand for their 
works. 

This invention thus solves the fundamental CD and 
Optical publishing problem of how to provide end-users 
with disk libraries containing many different publica- 
tions from different venders. Different properties from 
different publishers have differing significances in the 
today's marketplace. These products have prices which 
each reflect vendor investment, product specific market 
demand, and other vendor product marketing consider- 
ations. The present invention allows each vendor to set 
a price for their product(s) carried on CD or other 
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media publications. The invention has an interlock sys- and distribution in accordance with the present inven- 
tem that prevents access to the non-volatile storage tion — and the presence of such publishers in the mar- 
media (such as a CD-ROM disk) unless the user has ketplace will make it economically necessary (and feasi- 
contracted for the use of the disk and has a hardware ble) for other publishers who have second tier proper- 
plug-m module incorporating software. 5 ties to contribute to the same information base product. 

When a customer makes use of stored data, the inven- The present invention may also include an optional 

tion monitors which files are accessed and how much security system which allows an organization to pre- 

lnformation is requested by the user to be displayed. In V ent usage of all or a portion of an information base 

one embodiment of the present invention, information un less the user enters his security code. Multiple levels 

that is being reviewed or browsed may be distinguished 10 of security codes can be supported to allow restriction 

from information that is read into a host computer for of ^ individual's access according to his security autho- 

the purpose of copying, modifying, or telecommunicat- rfzation level 

ing, with _ different .cost rates being applied to the differ- is signiflcant va i ue in using the present inven . 

ent activities so that, for example, the cost of browsing ti ^ certain ty ^ of non fuU . te £ in f ormation 

can be much less than the cos of copying or pnntuig) 15 bases . For electroniC( CD disk containing 

S^^?tT^" P *^ B ^^^ 0f comprehensive telephone white pages, telephone yel- 

X TlnhorL ' rCq T d low 88 additional optionsfindividual specific 

1. Telephone the publisher once every three months, „,i.«*L...,i :_«■„ /• i j- • 

establishing a modem link over which a request is trans- f dd, f on ^,. information (including estimated income 
mitted to Telecommunicate back to the publisher Ae 20 ^f 1 ' P«b 'cations received job type and position, so- 

meter usage data; or c,al number, and other information that is com- 

2. Mail to the publisher once every three months a patiWe ™ d legally available from one or more of the 
removable EPROM module that contains the metered VanOUS ^ com P™^ ™8 hi b * ** d with the 
usage data. P resent mventlon - 

The present invention thus prevents copying or 25 As a result of ! he P^" 1 invention > ^ telephone 

browsing of a protected information base without ade- °P eratul g companies providing directory listings can be 

quate compensation to the publisher and its information c ° m P«Kated on the usage of their data base, while the 

base property (data) suppliers. Each supplier of infor- maA order compares can ^so receive a revenue stream 

mation to an information base product receives a return based on both "sexiness of their data bases usefulness to 

on'investment that reflects both the market demand for 30 customers md the extent of customer usage of their 

his specific property and the pricing and other market- ^formation. The present invention provides, for the 

ing strategies that the supplier deems appropriate for his flrst time ' a conte xt in which firms such as telephone 

product. t operating companies and other information property 

The present invention allows very large numbers of suppliers can safely and profitably supply information 

customers to acquire library disks at very low initial 35 for desk-top electronic information base products, 

costs, since the customer's billing can be largely based BRIEF DESCRIPTION OF THE DRAWINGS 
on usage, not simply possession of the library disk. As a 

result, potential customers, regardless of size or financ- These and other features and advantages of the pres- 

ing, will be able to maintain very broad based libraries ent invention will be better and more completely under- 

on-site. If a given group regularly uses only a fraction of 40 stood bv referring to the following detailed description 

the information base, the group's users can still search °f preferred embodiments in conjunction with the ap- 

the entire data base whenever appropriate. This means pended sheets of drawings, of which: 

that most user billing is concentrated on those reference FIG. 1 is a schematic block diagram of a presently 

resources that the users frequently use, but an entire, preferred exemplary embodiment of a database usage 

comprehensive reference library extending beyond the 45 metering and protection system in accordance with the 

user's frequent requirements is immediately available present invention; 

for use. A publisher will be in a much better position to FIG. 2 is a schematic block diagram of the informa- 

provide large scale reference information base libraries. tion stored in the storage medium block shown in FIG. 

In many applications, the breadth and comprehensive- 1; 

ness of these encyclopedic libraries will encourage 50 FIG. 3 is a more detailed schematic block diagram of 

much more frequency use and a much larger body of the decoder/biller block shown in FIG. 1; 

users. FIGS. 4a-4b are together a flow chart of the steps 

The present invention thus answers both the needs of performed by the system shown in FIG. 1; and 

a potentially very large customer base for low cost FIG. 5 is a schematic block diagram of a further 

initial access to comprehensive digital disk base refer- 55 presently preferred exemplary embodiment of a data- 

ence libraries, while at the same time maintaining base usage metering and protection system in accor- 

supplies publisher control over pricing and guarantee- dance with the present invention, and 

ing an appropriate return on investment based on the FIG. 6 is a flowchart of an overall method for receiv- 

customer's demand for their products. ing a return on investment from data bases at user sites. 

wsysst tsstzs 60 detailed °«ssssss preferred 

publishing market, since these owners are likely to be EMBODIMENTS 
particularly sensitive to the issues of unauthorized ac- FIG. 1 is a schematic block diagram of a presently 

cess to and copying of their product, pricing of their preferred exemplary embodiment of a database usage 
product, and equitable return on the value of the contri- 65 metering and protection system 10 in accordance with 

bution of their product to an information base library. the present invention. System 10 includes three main 

These publishers are likely to greatly increase their blocks: a storage medium block 100, a host computer 

revenues through participation in library publication 200, and a decoder/biller block 300. 
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Predefined database® is (are) stored on storage me- tion of the database and loading the encrypted rendition 

dium 100 in encrypted form, and selective portions of onto medium 100. One or more of the many sophisti- 

the database(s) are read from the storage medium by cated conventional data encryption schemes which 

host computer 200 (several different databases can be presently exist can be used for encrypting the database, 

stored on the same medium, although the present inven- 5 Preprocessing preferably also includes generating an 

tion in its simplest form uses only a single stored data- index to the database and storing the index together 

base which may contain multiple files, segments, "prop- with the encrypted version of the database on the stor- 

erties" or the like). Host computer 200 may be a com- age medium 100. The index may or may not be en- 

puter dedicated to the task of accessing the stored data- crypted. 

bases, but need not be (for example, the host computer 10 The preprocessed database may be loaded onto stor- 
can be a general-purpose digital computer used to do a age medium 100 in a conventional fashion. For example, 
variety of different tasks). a "master" medium may be prepared, and then simply 
Decoder/biller block 300 is connected to host com- duplicated to yield a number of duplicate storage media 
. puter 200, and performs at least two important func- 100. Storage of the entire preprocessed database (or 
tions. Decoder/biller 300 decrypts portions of the 15 databases) may require several storage medium units 
stored databases on a user need basis (e.g., after con- (i.e., several optical disks), each unit storing a part of the 
firming the user has proper authority to access the data- database. The database can index one or more databases 
bases)(see FIG. 6, block 904). Decoder/biller 300 also each containing one or more files, documents or "prop- 
meters database usage, and generates usage information erties" (the term "properties" referring to a literary or 
in a form which can periodically be conveyed to the 20 other textual work protected by copyright), 
owner of the databases (or his agent, e.g., a service FIG. 2 shows one exemplary scheme for storing data- 
company) (see FIG. 6, blocks 906-908). The usage in- base information on medium 100. The information 
formation is typically used to calculate a database ac- stored on medium 100 includes an index portion 102 and 
cess fee the user is to be charged (see FIG. 6, blocks an encrypted database portion 104. Database portion 
910-914). 25 104 includes a plurality of predefined quantities, or 
Decoder/biller block 300 may take the formof a hard- "blocks", 106 of digital data Each block 106 includes 
ware unit (or card) electrically connected to and Io- three information "fields" an index key field 108a; an 
cated in proximity to (or within) host computer 200, or encrypted database information field 1086; and a de- 
computer software executing on the host computer. cryption key/error-checking field 108c. 
Alternatively, decoder/billing block 300 might be lo- 30 Index portion 102, which may be encrypted, provides 
cated remotely to host computer 200 and communicate information used to translate a database access request 
with the host computer via a data communications net- into the addresses of one or more blocks 106. The con- 
work or a telephone line. tents of index portion 102 depends on the type of data- 
Storage medium 100 is preferably some form of inex- base stored on medium 100 and the type of operations 
pensive mass digital information store (e.g., an optical 35 which are to be performed on the database. For exam- 
disk, a bubble memory or a large hard disk or other fast pie, if word or string searching is to be provided, index 
transfer rate magnetic storage technology) prepared by portion 102 may include a list of all of the words con- 
the database owner and licensed to the user for use. tained in the database and the blocks 106 in which the 
CD-ROM, GDI, WORM, and other related optical/- listed words appear. Index portion 102 may alternately 
digital very large capacity storage modalities are now 40 (or also) include a "table of contents" of the database 
coming to the personal computer market and can be and a designation of the blocks 106 covering each entry 
used for this purpose. These products are highly reli- in the table. Other ways to index a database are known, 
able, and very economically store hundred of mega- and the present invention is not limited to any particular 
bytes up to multiple gigabytes of data. indexing scheme. 

For example, a CD-ROM diskette stores 550 mega- 45 Index key 108a of each block 106 stores data which 

bytes of information on a single 12 centimeter laser can be referenced in accordance with information 

diskette. CD-ROM technology now being released to stored in index information portion 102. Index key 108a 

the market will economically support up to eight paral- may be explicit (e.g., a digital data word representing an 

lei drives (4 gigabytes or 1,800,000 printed pages) and indexing code or address) or implicit (e.g., physical 

will access any desired sector in one second. In the next 50 "addresses" of storage medium 100 may themselves be 

several years, technological advances should reduce used as indexing keys). 

access time to 4 second, and storage capacity will be Encrypted database information fields 1086 contains 

doubled (450,000 pages per diskette and 3,600,000 pages predetermined portions of the encrypted database. The 

on-line) if CD-ROM manufacturers decide to market size of these portions may be determined by the particu- 

double-sided disks and drives CD-ROM, CDI, and 55 lar hardware and/or encryption techniques used, and is 

WORM products will be increasingly affordable over preferably (but need not be) fixed. If the nature of the 

the next 30 months, with CD-ROM prices estimated to database permits, logically-related information should 

drop from $800.00 to $400.00 or less per drive, includ- be stored in the same blocks 106 (i.e., the database 

ing controller, and OEM and volume prices estimated should be presorted and hierarchically organized) to 

to drop to as low as $175.00 per unit by 1990. With 60 reduce the number of accesses of storage medium 100 

CD-ROM, WORM, and other optical/digital technolo- required to respond to a single user request. Techniques 

gies, users can both purchase large scale information for organizing databases are known to those skilled in 

bases and also themselves easily build organization- the art of information retrieval and database design and 

specific information bases. management. 

The database is preferably "preprocessed" and then 65 Decryption key/error-checking field 108c performs 

stored onto medium 100. The type of preprocessing two functions in the preferred embodiment. First, it 

performed depends upon the database and the applica- provides conventional error checking (e.g. CRC or 

tion, but typically includes creating an encrypted rendi- parity) information useful for detecting information 
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reading errors. Secondly, the field may provide infor- index is stored on the storage medium is itself used to 
mation needed by sophisticated data decryption make information incoherent unless it is read from the 
schemes to decrypt the information stored in associated medium using a predefined access algorithm, 
field 108& In many data decryption schemes, a decryp- For example, records of the database may be non- 
tion key word (which may itself be encrypted) carried 5 contiguously stored on medium in a pseudo-random 
with the encrypted data is used in conjunction with an order, so that sequential reading of records produces 
additional data decryption key generated by the data only incoherent information. An index stored on me- 
decrypting device to decrypt the data. Field 108c may dium 100 contains the information needed to locate 
or may not be required depending upon the error check- logically sequential database records. This index ("di- 
ing and decryption schemes employed. 10 rectory map") may also be in some way "scrambled" 

Host computer 200 contains resident software and (for example, encrypted using formal encryption tech- 
hardware which provides an interface for all database niques, perhaps simply incomplete so that it must be 
transactions. Computer 200 includes one or more appro- supplemented with information and/or algorithms con- 
priate I/O handlers and associated hardware device tained in decoder/biller block 300, or another scheme 
drivers which permit the computer to read information 15 can be used to properly interpret the directory map, 
from storage medium 100. Host computer 200 also in- directory map interpretation being necessary to deter- 
cludes appropriate data communications software and mine the locations on medium 100 of the components of 
associated hardware which permits it to exchange data a given database or other "property"). Different index 
with decoder/biller block 300. The data communica- scrambling schemes can be used for different copies of 
tions pathway between host computer 200 and deco- 20 storage media 100 to preventdevelopment of a "univer- 
der/biller block 300 may be a shared data bus, a dedi- sal" de-scrambling device or algorithm, 
cated I/O channel, a shared data communications net- Decoder/biller block 300 measures the amount and- 
work, or the like. /or type of information sent to it for decryption and 

When a user requests information from the" database stores information indicating database usage over time 
stored on storage medium 100, the computer program 25 from such measured amounts. Decoder/biller block 300 
resident on computer 200 controls hardware of the stores all necessary billing and usage information in a 
computer to read the index information 102 stored on protected, non-volatile memory device (or in a pro- 
medium 100 in order to ascertain which database blocks tected, non-volatile storage facility within the host com- 
106 contain information specified by the user request. puter 200) for later retrieval and use in calculating data- 
The computer program then controls host computer 30 base usage fees. 

200 to load one or more blocks 106 of the stored data- Because the database information read from medium 
base information into the host computer memory. The 100 is useless unless it is first decrypted, and decoder/- 
host computer 200 then, under software control, strips biller block 300 is the only portion of system 10 which 
off the contents of encrypted fields 1086 from the blocks is capable of decrypting the encrypted database infor- 
of information now resident in its memory (along with 35 mation, the decoder/biller block can accurately meter 
some or all of the contents of decryption key/CRC field the amount and nature of data accessed from the stored 
108c) and sends some or all of this information to the database {e.g., by counting the number of blocks 106 
decoder/biller block 300 for processing. which are encrypted, determining the group of logi- 

Because the index portion 102 is notencrypted, host cally related information ("property") stored on me- 
computer 200 can manipulate the index information 40 dium 100 which is logically associated with the data 
without involving decoder/biller block 300. Although being decrypted, and/or determining other convenient 
this is an important advantage in some applications parameters indicating the quantity and/or identity of 
(since the user is permitted to "browse" through the data which is decrypted}. Decoder/biller block 300 
index "for free"), other applications may demand a level decrypts the information sent to it, and returns the de- 
of security which is compromised by providing an 45 crypted information to host computer 200 for display, 
unencrypted index. For example, unencrypted, very storage, printing, telecommunications, or the like (or 
complete indexes might be used to reconstruct signifi- otherwise makes the decrypted information available to 
cant portions of the database itself. It may therefore be the user). 

desirable to encrypt index portion 102 as well as data- FIG. 3 is a more detailed schematic diagram of the 
base portion 104 to provide higher security. 50 decoder/biller block 300 shown in FIG. 1. Block 300 

If index portion 102 is encrypted, it must be de- includes the following a tamper-proof mechanism 302; a 
crypted before a user can make selections from it or data connector 304 for connection to the host computer 
otherwise use it to locate blocks 106. Decryption of 200; a data connector 306 for connection to an off-site 
index portion 102 should be performed in a secure envi- service decryption logic 310; interface logic 312; a non- 
ronment (such as in decoder/biller block 300, or in a 55 volatile memory 314; decoder control logic 316; and a 
dedicated "browsing workstation" to be discussed in real-time clock/calendar 318. 

connection with FIG. 5). Alternatively, decoder/biller Tamper-proof mechanism 302 prevents unauthorized 
block 300 may temporarily provide host computer 200 persons from electronically or mechanically tampering 
with the decryption key information needed to decrypt with decoder/biller block 300, and preferably includes 
index portion 102 (the index portion may be encrypted 60 both mechanical and electronic safeguards. For exam- 
using an encryption technique which is different from pie, the physical enclosure which encapsulates the com- 
the one used to encrypt database portion 104), and the ponents of block 300 should prevent unauthorized indi- 
host computer can decrypt sections of the index portion viduals from accessing the enclosed components. The 
as needed by the user. components can be epoxied or potted if desired, and/or 

In one possible permutation of the invention, neither 65 the enclosure can be provided with a mechanical seal 
the database nor the index stored on medium 100 is which clearly evidences any tampering, 
"encrypted" using a formal encyrption algorithm, but Another safeguard against tampering can be pro- 
instead, the manner in which the database and/or the vided by implementing one of more of functional blocks 
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308-318 in the form of a custom integrated circuit. Such face logic 308 and interface logic 312 may comprise the 

custom integrated circuits are not easily reproducible same components. 

by an unauthorized person, nor could functional equiva- Database decryption logic 310 takes input digital data 

lents be designed ("black-boxed") so long as the tech- signals provided to it by decoder control logic 316 

niques used to encrypt and decrypt the database are 5 (these signals representing encrypted digital data read 

sophisticated. This level of data encryption sophistica- by host computer 200 from storage medium 100 and 

tion is well within present technology. passed to the decoder control logic via connector 304 

Connector 304 and interface logic 308 communicate *nd interface logic 308), decrypts these digital data 
data between decoder/biller block 300 and host com- signals using a predefined decryption algorithm, and 
puter 200. Interface logic 308 includes conventional 10 outputs decrypted data signals to the decoder control 
electronics which interface host computer 200 with logic for display, printing, and the like. One or several 
decoder control logic 316. Interface logic 308 is elec- different predefined decryption algorithms can be 
tronically connected to physical electronic connector stored in (or hardwired within) decryption logic 310, 
304, which in turn is connected to a mating connector of 311(1 additional decryption algorithms can be down- 
host computer 200. 15 loaded into the decoder/biller block 300 as needed or 

The exact configuration of interface logic 308 and required via interface logic 312. 

connector 304 depends upon the nature of host com- Man y conventional methods of encrypting/decrypt- 

puter 200 and sort of data communications pathway in 8 data m known, spanning from simple lookup tables 

desired. For example, in one exemplary arrangement, t0 complex mathematical algorithms. The method of 

connector 304 comprises a host computer bus connec- 20 data encryption/decryption used depends on the 

tor (connected to the main bus of host computer 200 and amount of extra computer processing overhead and 

addressed directly by the host computer processor) and data stora g e s P ac e that the application will allow. It is 

interface logic 308 comprises a bus interface. Of course, not uncommon for substantial overhead to be needed to 

connector 304 could comprise a standard RS-232 port „ nan , dle encrv Pted data. 

connector and interface logic 308 could comprise con- 25 . To ^.taU system 10, storage medium 100 (along with 

ventional port interface logic - or the interface logic lts associated dnve/access device) is connected to host 

could comprise a communications controller (e.g.fa com P ut ,f r f°> and ^coder/biller 300 is ako connected 

data communications network controller or a modem) * t £^2Tf. "^hw" *" ^. COnnectm S 

and the connector 304 could be a standard communica- , n SST2^ JST^i, n0B 7° , f? m ' m0 5 y 

tions connector (if decoder/biller block 300 were lo- 30 SJJLS^TSl^ has been preloaded wi h the 

cated remotely from host computer 200). nTt \ 1/ upon installation): 

Other communications connectors and/or ports £ J** * , key(s) , ^ USer P^f^): A 

u„ ..--j <u _ * ./ F (b) billing rates (optional — may be performed by the 

might be used for connector 304, the specific arrange- data b ^ e QWn( £ at Ws QWn y ^ y) 

TnlT JT g on the application, con- 35 (c) date ^ ^^^^ X^^. ^ 

veiuent performance and/or cost Other possible ar- (d) user i de „tification(s)/security levels (if des red). 

SKT* P - 8 , dec0der ^! ller "?* FIGS. 4(A)-4(B) are together a high-level flowchart 

300 into the same housing contauung the drive which of the routine ^ performed by system 10 to access a 
access^ medium 100 ^ or connected to (or actuaUy con, port ion of the stored database. 

nected as part of) cablmg connectmg the drive for me- 40 To access database M otmlltiont ±e ^ causes host 

dium 100 to host computer 200, can be used com uter 20 0 to execute software resident within it 

Decoder control logic 316 preferably includes a con- which pe^ ±t user t0 formulate a database access 
ventional microprocessor pre-programmed with a pre- request (block 402). As discussed above, the nature of 
determined control computer program, but might be the access request depends on the nature of the database 
implemented in other ways (e.g., as a discrete digital 45 the needs of the user. Most users require the ability 
logic sequential state machine). Decoder control logic t0 perform i exical database searches (i.e., searches for 
316 controls all of the functions of decoder/biller block wordS) stringSi and the like)> However, other methods 
300 in the preferred embodiment. Decoder control of accessing information are also possible. For example, 
logic 316 also monitors database usage, produces digital if the database is a literary novel, the user's access re- 
data indicating the amount of such usage, and stores this 50 quest might be a chapter number and/or page number, 
data in non-volatile memory 314 for later retrieval(e.g., Personal Library Software, Inc. of Bethesda, Maryland, 
by a service company or the database owner). 0 ff ers advanced indexing software technology which 

Real time clock/calendar. 318 permits database usage allows a user to perform both keyword and topical 
metering to indicate the time and date of each usage and searches (contrasting with other commercial products, 
the duration of usage, thus providing an important audit 55 which are limited to keyword searching techniques), 
tool for both customers and the service company. In Personal Library software can be used to great advan- 
addition, this real-time clock/calendar 318 can be pre- tage with the present invention, 
programmed to allow the user to access certain data- The user then inputs an access request (block 404) 
bases only at pre-programmed times (e.g., by limiting using a keyboard or other standard I/O device con- 
access for given user security access codes). 60 nected to host computer 200. In response to the user's 

Interface logic 312 and connector 306 may be used to access request, host computer 200 accesses index por- 
communicate data with an off-site facility, such as the- tion 102 stored on medium 100 and obtains from the 
centralized computer of the database owner or a service index portion the addresses of (or index keys corre- 

company which handles periodic database usage billing. sponding to) each block 106 of the encrypted database 
In one exemplary embodiment, connector 306 includes 65 which satisfies the user's access request (block 406) 
a standard telephone connector and interface logic 312 (index portion decryption is performed at this time if 
includes a standard modem. If desired, connectors 304 necessary). Host computer 200 then reads the appropri- 
and 306 may comprise the same connector, and inter- ate block(s) 106 of the encrypted database from storage 
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medium 100 and stores these blocks of information into for only one similarly coded storage medium (or for 

its own internal random access memory (block 408). only one or a few databases stored on a particular stor- 

System 10 may require the user to input identification age medium). The coding of storage medium 100 with 

and/or password information along with his access embedded, user-identifying codes would also help to 

request (block 404). System 10 checks the authority of 5 identify how any unauthorized copies of the database 

the user to access the database by transmitting the input- information came into being, since the coded informa- 

ted ID/password information to decoder/biller block tion would be embedded in the database information 

300 for comparison with a list of authorized IDs/pass- itself and would thus also be present in any copies made 

words stored in memory 314 (block 410). If decoder/- from ^ orig i na l. Users found in this manner to be in- 

biller block decoder control logic 316 denies authoriza- 10 vo i ved in copyright infringement could be penalized 

tionto continue with database access (because the in- appropriately under the civil and criminal penalties of 

putted user information is incorrect, because the access the copyri ght law, as well as for breach of their contrac 

request cannot be performed at the current time/date, tua i obligations 

etc.) (block 412), the decoder/biller block refuses to Decoder colUrol x ic 316 ^ is enabled at this ^ 

t™T T y H T Z ? l0 t Ck4M) T °, eaSe 15 10 < a > decrypting information sent to it by host 

^Tvl^^fnv , H° St f C °T Ute ^ 20 2' ? d/OT com P uter 200 and (b) sending the decrypted informa- 

•? ^^P t&d t m !°^f on th 5 hos t c ° m - tion back to the host computer (block 418). Decoder 

£™S enCryP mfomata ° n n I s control logic 316 meters the quantity and/or other 

used for ally useful purpose. tbls " f °T T "" V ° 'L™?^ ?l* 
On the other hand, if decoder control logic 316 of f ° therb,lhng ln f ormatlon (Mock «0) (the 
decoder/biller 300 grants authority to proceed (block decoder J 50 "*? 1 loglc may store " ua . nt,ty information 
412), the decoder control logic begins a "billing cycle", ^ ctly f° W T" y .' ° f may ° 0nVert lt t0 
and stores information logging the billing cycle into 25 ^^f^^^^^^ 0 "^^ 
non-volatile memory 314 (block 416). The information cost of usln ? da !f base file bem « accessed). This 
stored in memory 314 may include: (a) the name of the P r ° cess contmues ***** ™ er s 8 rec l uest has been satis " 
database file being accessed; (b) the section of the data- tested f ° r b _ y 1I block 422 >' , „ , 
base being accessed (name, "property designation", file user can be bllled «" aanu>1 fee for ™I>"ited use 
name, or other identification information); (c) the iden- 30 of some databases or database properties, and billed 
tification of the user accessing the database; and (d) the only for actual use of other databases or database prop- 
date and time the database access begins. erties - In this wa V> ^ user can P a y a fla t fee for the 
The information stored in non-volatile memory 314 databases, or specific database properties or "books", he 
may thus be used to create an "audit trail" which tracks most often > ^ yet " av e access on a "pay-as-you- 
different users (or groups of users) and their database 35 8°" basis t0 other databases which he might use occa- 
usages. Special use passwords may be required to access sionally but not enough to justify paying the cost for 
selected databases, and actual use of all databases may unlimited use. This billing method provides the user 
be verified later from the information stored in memory with database resources he might not otherwise be able 
314. Such stored information is extremely valuable not to afford, and also stimulates use of databases which are 
only to help detect unmonitored database use, but also 40 not used often but are nevertheless extremely valuable 
to allow detailed bills to be generated and to help deter- at times. 

mine which users among multiple users are responsible The specific steps performed to decrypt data (block 
for generating usage charges. Such a detailed audit trail 418 ) depends on the particular data encryption/decryp- 
can be used to allow publishers and users to determine tion scheme used. Host computer 200 transmits en- 
the detailed activities of users. This information can be 45 crypted data in predetermined quantities (e.g., fixed- 
used by users to determine what they are being charged length blocks) to interface logic 308 via connector 304 
for. The audit trail information can also be used by m the preferredembodiment. Interface logic 308 corn- 
publishers and property owners to conduct marketing municates this encrypted data to decoder control logic 
surveys — providing more detailed information about 316, which communicates it to data encryption/decryp- 
user demographics and information use than is presently 50 tion logic 310. Logic 310 translates the encrypted data 
available. into intelligible information using a predetermined con- 
In addition, it may be desirable to code storage me- ventional decryption algorithm, and communicates the 
dium 100 (or particular databases or files stored on the decrypted data back to decoder control logic 316. De- 
medium) with unique (e.g., randomly-generated) user coder control logic 316 then communicates the de- 
passwords by embedding secret password information 55 crypted data to host computer 200 via interface logic 
in the database information. Non-volatile memory 314 308 and connector 304. 

can store information which matches the code associ- The database access program resident in the host 

ated with the particular copy of the storage medium computer then controls the host computer to display 

licensed to a particular user. This coded information and/or print the decrypted information. If desired, the 
can be encrypted, and coding schemes and/or coded 60 program resident in the host computer 200 can prevent 

information may be changed periodically. Different the user from doing anything other than displaying 

users can be assigned different codes to prevent users (and/or printing) the decrypted data. Alternatively, this 

from exchanging or sharing storage media 100. program may permit the user to manipulate the de- 

This additional security feature also impedes the use crypted text (e.g., store the data in a disk file or in the 
of unauthorized decoder units (e.g., clandestine units 65 memory of the host computer) to permit the user to 

manufactured to be similar to block 300). Such unautho- browse through full-text data at his leisure and/or to use 

rized units would not be equipped with the correct this data for word processing, telecommunicating, or 

coded information, and even if they were, would work the like. 
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Decoder control logic 316 meters database usage computer, and the service company computer then 
(block 420) by, for example, measuring the amount of transmits commands which control decoder control 
information which is decrypted (e.g., by counting the logic 316 to reset the memory. In addition the service 
number of fixed-length blocks which are decrypted; company can establish communications with decoder/- 
determining the source documents the decrypted infer- 5 biller block 300 to monitor use of the databases stored 
mation is associated with; and measuring the time, date on medium 100 (and detect misuse and unauthorized 
and/or duration of access of the decrypted informa- use). The service company may also control decoder/- 
tion). Control logic 316 may also record other billing biller block 300 remotely (e.g., to disable it from operat- 
infonnation, such as the length of the database file being ing if customer fails to pay his bill), 
opened. Control logic 316 may be arranged to recog- 10 System 10 may include an enabling/disabling mecha- 
nize the names or other designations of subsections of nism which prevents a user from accessing the stored 
the database being accessed, allowing for different bill- database information if he fails to pay his bill. For exam- 
ing rates depending on the type or supplier of the infer- pie, in the embodiment discussed above having a separa- 
mation (so that use of more expensive databases can be ble memory module 314a, the service company can 
billed at higher rates). 15 refuse to mail the user a replacement module until all 

It may be desirable to not bill users for simply search- outstanding balances are paid. If the customer fails' to 
ing through the database (or at least, not bill at the full pay his bill, he will eventually fill up the memory mod- 
rate), but to bill only or at a higher rate for data that is ule he has installed, causing decoder control logic 316 
decrypted and displayed, printed or communicated. It is to disable data decryption (or alternatively, the modules 
for this reason that the database index is not itself en- 20 314a can be electronically date-coded, and the decoder 
crypted in one embodiment — so that the user can control logic can refuse to permit decryption to be 
browse through the index "for free" (or at a lower performed when the module date code is determined to 
charge). As mentioned previously, however, it may be be prior to the current date generated by real time 
desirable in some instances to provide additional secu- clock/calendar 318). 

rity by encrypting the index as well as the database. If 25 Decoder control logic 316 can be disabled from oper- 
decoder/biUer block 300 decrypts the index, it can ating if the real time clock ever ceases to operate (for 
meter index usage and store this usage information into example, the clock may be battery powered and the 
non-volatile memory 314 — thus permitting the user to battery might go dead after a year or so if scheduled 
be billed for index browsingat comparatively low rates. preventive maintenance is not performed). Once the 
A dedicated "browsing terminal" (to he discussed 30 real time clock is repaired, a communications link can 
shortly) may be used in some applications to provide a be established between decoder/biller block 300 and the 
secure environment in which browsing can occur and central facility. The central facility can then read the 
billed at a rate which may differ from that for database contents of non-volatile memory 314. If no suspicious or 
information usage (e.g., printing, telecommunicating, unauthorized activities have occurred, the central facil- 
copying, etc). 35 ity can reset real time clock 318 or check a locally set 

After the user's access request has been satisfied (as real time clock to permit normal database decoding 
tested for by block 422), the decoder control logic operations to resume. 

stores, into non-volatile memory 314, the time the user Another arrangement can control decoder control 
finishes accessing the database, (block 424). The resi- logic 316 to periodically, automatically change autho- 
dent program then allows the user to input another 40 rized passwords — and the service company can refuse 
access request (using the same of different database) to tell the customer the new passwords until the cus- 
(block 426). If the user does input another access re- tomer has paid his bill. 

quest, the steps of blocks 404-426 are performed again Alternatively or in addition to the arrangements dis- 
(with blocks 416, 420 and 424 causing an additional cussed above, system 10 may be provided with an auto- 
billing log entry to be stored in memory 314). 45 matic "self-destruct" mechanism which automatically 

The information stored in memory 314 is periodically "destroys" a critical part of the system (e.g., the infor- 
communicated to the service company and used to bill mation stored on medium 100, or the password table 
the user for database usage. In one exemplary embodi- stored in non-volatile memory 314) at a preset real time 
ment, memory 314 is housed in a storage module 314a deadline (timed by real time clock/calendar 318) unless 
which is easily separable from system 10. Periodically, 50 the customer implements an "antidote" (e g., inputs a 
the user disconnects memory module 314 from deco- series of secret code words) prior to the deadline. The 
der/biller block 300, mails the module to the service service company can provide antidote instructions only 
company, and installs an alternative replacement mod- to customers who have paid their bills This automatic 
ule (the "next" module) into system 10. Decoder con- "self-destruct" mechanism can also be activated when- 
trol logic 316 disables data decryption unless a module 55 ever the customer exceeds a predetermined maximum 
314a is connected to it (and perhaps also when the con- (and/or minimum) usage limit (so as to prevent a cus- 
trol logic has determined the non-volatile storage area is tomer from running up a huge bill, from attempting to 
nearly full). decrypt and store substantial portions of the unen- 

In another embodiment, communications between crypted database, or from continuing to use the data- 
decoder/biller block 300 and the service company is 60 base in the unlikely event that he has successfully pre- 
periodically established for the purpose of downloading vented the logging of usage information). If additional 
the contents of memory 314 to the service company protection against database piracy is desired, the auto- 
billing computer. If connector 306 and programming matic "self-destruct" mechanism can also be activated 
interface logic 312 comprise a conventional standard whenever the user attempts to access, in one session or 
telephone connector and associated modem, such com- 65 over a number of different sessions or within a given 
munications can be established over standard telephone time frame, more than a certain percentage of a given 
lines. The information stored in memory 314 is transmit- database and/or more than a certain number of contigu- 
ted over the telephone line to the service company ous blocks of (or logically related records or other 
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subdivisions of) the same database. A permanent record a telecommunications link to provide extremely current 
of the blocks (records or other subdivisions) which have information in addition to the "older" information pro- 
been accessed may be retained in non-volatile memory vided on-site. 

314 so that the user can be prevented from copying an There are thus both advantages and disadvantages to 

excessive amount or selected database properties or 5 the "direct connect" mode. This mode may be offered 

segments over a period determined by the database as an option for users who require up-to-the-minute 

owner. updated databases. 

It may also be desirable to enable the user to program Once data is decrypted and stored into the memory of 

parameters stored in non-volatile memory 314 which host computer 200 (e.g., for searching or manipulation 

limits the user's own use of database information stored 10 rather than simply for display), it is susceptible to being 

on medium 100. The routine shown in FIGS. 4(A)-4(B) intercepted by a "pirate" intercept program. System 10 

can provide a user interface with decoder/biller block bills for the data which is decrypted (so that the user 

300 which permits a user to optionally store, in a user- would run up a huge bill if he tried to copy a large 

accessible file within memory 314, information repre- portion of a database). Nevertheless, it may be desirable 

senting ceilings on database usage or cost of usage over 15 in some applications to restrict the manner in which a 

a period of time (e.g., a maximum monthly duration or customer can use decrypted data, while at the same time 

cost for database usage, limitations on the type of infor- not restricting manipulations (e.g., browsing) of the 

matioii which can be decrypted, etc.). Decoder/biller decrypted data. 

block 300 keeps a running total of the parameters) the For example, keyword searching does not require a 

user has specified, and ceases decrypting database infor- 20 data image of the database (rather, it is most efficiently 

mation if the total exceeds the user-specified parameter performed using index information 102). However, 

value. This feature permits the user to budget his data- other search techniques (e.g., final "zooming in" of the 

base use, and is especially valuable in a business envi- information being searched for) may require manipula- 

ronment — since it permits an organization to directly tion of a data image. It may bedesirable to absolutely 

limit the cost of database access by employees to an 25 prevent the user from copying the decrypted data 

amount selected by the organization. image information. However, the user should be able to 

Although the embodiment shown in FIG. 1 is partic- manipulate data images in other ways (e.g., by browsing 
ularly suited for installation at a customer site, some through full-text data and the like). It may be impossible 
applications might necessitate that decoder/biller block to impose such restrictions on data stored in the user's 
300 and storage medium 100 be operated remotely to 30 own host computer 200 (or the user may be able to 
the customer site and communicate information to the easily defeat such restrictions once imposed through 
customer via a communications link (e.g., a standard skillful programming techniques), 
telephone line). In this "direct connect decryption" FIG. 5 is a block diagram of an alternate embodiment 
mode of operation, data decryption is performed at a of a database usage metering and protection system 500 
central facility of the service company. Since only a 35 in accordance with the present invention. The FIG. S 
small portion of the database is decrypted at any one embodiment includes a dedicated independent hard- 
time, a telephone line provides sufficient bandwidth to ware unit ("browsing workstation") 501, which can 
transmit the decrypted data at rates suitable for display either act as a "stand-alone" or be designed to interface 
by the customer's computer. with additional data processing components. 

Using the "direct connect" mode, there is no need for 40 Browsing workstation 501 in the preferred embodi- 

periodic exchange of service storage modules or for ment includes a proprietary, single-board computer 502 

pre-scheduled periodic communications with the local connected to a dedicated proprietary display station 504 

host computer. Billing data could be accrued in real having a secure environment. Computer 502 includes a 

time, and the service company coulddisconnect or bus connector 506, a host interface 508, a CPU 510, a 

change the service of a customer at any time. Database 45 volatile, protected memory 512, a non- volatile memory 

updating is also simplified, and current information or 513, and a display driver 514. Computer 502 is enclosed 

changing data is always at hand (since it can be auto- in a tamper-proof enclosure 516 to completely prevent 

matically included in a user database search). More- access to its internal components except by authorized 

over, the user can use just about any kind of computer service personnel. 

to access the service company central facility. Further- 50 Computer 502 performs the decryption and billing 
more, the connect time charges for communication functions discussed previously, and then stores the de- 
networks are becoming more competitive in price, mak- crypted data into its own memory 512. This arrange- 
ing this "direct connect" mode attractive for some ap- ment allows the user to review ("browse") the informa- 
plications. tion (on dedicated display station 504) prior to sending 

The chief disadvantages of this "direct connect" ap- 55 desired information to his host computer (via interface 

proach are: Database access speed is much slower than 508 and connector 506) for printing or other use. Thus, 

in the locally-installed embodiment discussed above the decrypted database data image is first stored and 

(because of the shared nature of the central facility and manipulated by computer 502. The user can be billed at 

because of the relatively low data transmission rate of one rate for browsing through or otherwise manipulat- 

standard telephone lines); communications costs are 60 ing data in computer 502, and billed at a higher rate for 

much greater; and the service company must purchase transferring data to his host computer (from which the 

and operate an expensive multi-user computer facility. data can be printed, stored, outputted, or telecom- 

The "direct connect" and the locally stored database municated to other computers and users), 

features might be used together in some applications. The user can evaluate the data while it is resident in 

For example, the bulk of a database can be stored on 65 computer memory 512 (via display station 504) in order 

arid accessed locally from a local storage medium 100. to decide whether or not he really wants the informa- 

Database update file information can be stored and tion transferred to his own host computer. In this way, 

updated at a remote centralized facility and accessed via very different billing rates can be provided for (a) 
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browsing large amounts of full-text information and (b) 
actual use of information in the host computer (e.g., for 
word processing, telecommunications, printing, etc.). 

Browsing workstation 501 may share some ofthe 
hardware and/or software of a host computer in order 5 
to reduce hardware costs — so long as information 
security is not significantly compromised. For example, 
one of the workstations normally connected to the host 
computer and its associated driver might be used in lieu 
of dedicated display station 504 and display driver 514 if 10 
there is little or no possibility that the user could copy 
a significant part of a database by reading information 
produced by the host computer display driver while 
browsing is in progress. 

In a further embodiment, sophisticated software (not 15 
susceptible to manipulation or other misuse) could be 
temporarily loaded into the host computer (e.g., from 
storage medium 100) and executed to provide the func- 
tionality of some or all of the hardware "blocks" shown 
in FIGS. 3 or 5. Such software might use the security 20 
system provided by the host computer (and/or sophisti- 
cated techniques which are difficult to discover and 
"break") to create a protected environment within the 
host computer itself for decryption of database informa- 
tion and non-volatile storage of database usage informa- 25 
tion which may be adequately secure for various appli- 
cations. 

For example, although it may be undesirable to per- 
mit data type decryption key information to reside in 
the host computer permanently, the decryption key 30 
information can be temporarily provided by a protected 
memory device to the host computer. The host com- 
puter may then decrypt database information using the 
decryption key information, and destroy the key infor- 
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closed embodiments, but on the contrary, are intended 
to cover modifications, variations, and/or equivalent 
arrangements which retain any of the novel features and 
advantages of this invention. 
What is claimed is: 

1. A secure data base access system comprising: 

at least one storage medium storing at least one en- 
crypted textual database component and at least 
one index associated with said component; 

input means for providing database index search cri- 
teria in response to user input; 

searching means operatively connected to said at 
least one storage medium and to said input means 
for searching said database, including means for 
referencing said index based on said search criteria, 
for identifying portions of said encrypted database 
in response to said index referencing, and for read- 
ing one of (a) all of said identified database por- 
tions, and (b) desired ones of said identified data- 
base portions from said at least one storage me- 
dium; 

means, connected to said searching means, for de- 
crypting at least one portion of said read encrypted 
information; and 

control means operatively connected to said decrypt- 
ing means for metering usage of information de- 
crypted by said decrypting means and for telecom- 
municating said signals representing said usage to a 
remote location over a telecommunications net- 
work. 

2. A system as in claim 1 wherein said control means 
measures the number of contiguous blocks of said tex- 
tual information decrypted by said decrypting means 



mation after use. The host computer may decrypt data- 35 311(1 prevents said decrypting means from decrypting 



base information "on the fly" and not retain much en- 
crypted or decrypted information in memory at any one 
time to help prevent copying. 
Although a dedicated hardware/software system 



more than a certain number of said contiguous blocks. 

3. A system as in claim 1 wherein said control means 
measures the time duration over which at least one (a) 
of said searching means processes said information, and 



typically provides the best assurance against tampering, 40 0>) sa j d information is decrypted, and wherein said 
techniques which may be implemented in software exe- , "" J * '~ J 

curing on a non-dedicated system may provide suffi- 
. cient tamper resistance for some applications. For ex- 
ample, secure program control and usage information 
can be stored on a floppy disk which is accessed via the 45 
disk drive of a general-purpose non-dedicated personal 
computer. A non-volatile memory and logic device 
connected to the personal computer may (in conjunc- 
tion with the secure program control software execut- 
ing on the computer and/or a hardware controller con- 50 
nected to the computer) control and monitor the posi- 
tion of the read/write head of the disk drive, store the 
current head position in the non- volatile memory, and 
supervise execution of the secure programcontrol soft- 
ware. Database usage information may be gathered by 55 
the program control software and stored on the floppy 
disk. Any attempts to tamper with the floppy disk 
which alters the last read/write head position may 
cause a warning message to be stored on the floppy disk 
in a database audit trail section of the disk (possibly 60 
along with cumulative messages indicating previous 
such occurrences) and may also result in destruction 
and/or disablement of the secure program control soft- 
ware. 

While the present invention has been described with 65 
what is presently considered to be the most practical 
and preferred embodiments, it is to be understood that 
the appended claims are not to be limited to the dis- 



includes means for storing said n 
sured time duration. 

4. A system as in claim 1 or 2 wherein said metering 
means measures the duration of usage of said decrypted 
information. 

5. A system as in claim 1 or 2 wherein said metering 
means includes means for storing said usage informa- 
tion. 

6. A system as in claim 1 wherein: 

said stored encrypted information has logically- 
related segments; and 

said control means determines which logically- 
related segments said selected portions are associ- 
ated with. 

7. A system as in claim 1 wherein: 

said medium stores plural textual databases; and 
said control means meters usage of less than all of said 



8. A system as in claim 1 wherein said control means 
omprises: 

a physically separable non-volatile memory device; 
and - 

monitoring means, connected to said decrypting 
means and also disengageably connected to said 
memory device, for measuring the quantity of in- 
formation decrypted by said decrypting means and 
for storing indicia of said measured quantity in said 
memory device. 



23 

9. A system as in claim 8 wherein said monitoring 
means disables said decrypting means from operating 
unless said memory device is operatively engaged, 
thereto. 

10. A system as in claim 1 wherein said control means 5 



memory means for storing usage information; 

monitoring means, operatively connected to said 
decrypting means and also connected to said mem- 
ory means, for metering at least one of (a) the quan- 10 
tity of information decrypted by said decrypting 
means, (b) an identification of a subset of informa- 
tion stored on said medium containing said identi- 
fied portions, and (c) duration of at least one of 
searching, identifying, decrypting, reading and 15 
using of said database portions, for generating sig- 
nals indicating the result of said metering, and stor- 
ing said generated signals in said memory means; 
and 

means operatively connected to said decrypting 20 
means and to said memory means for preventing 
said decrypting means from decrypting informa- 
tion whenever said metered indicating signals are 
not successfully stored in said memory means. 

11. A system as in claim 1 wherein said control and 25 
communicating means includes: 

a memory; and 

monitoring means, operatively connected to said 
decrypting means and to a communications net- 
work, for monitoring the quantity of at least one of: 30 
(a) information decrypted by said decrypting 
means and (b) information identified by said 
searching means, for controlling said signal com- 
municating means to communicate an indication of 
said monitoring to a billing facility over said com- 35 
munications network. 

12. A system as in claim 11 wherein said monitoring 
means also determines identifying characteristics of at 
least one of (a) said decrypted portions and (b) said 
identified portions and controls said signal communicat- 40 
ing means to communicate said identifying characteris- 
tics to said billing facility. 

13. A system as in claim 1 wherein: 

said at least one storage medium also stores unen- 
crypted index information correlating unencrypted 45 
search information with portions of said encrypted 



14. A system as in claim 1 wherein: 

said at least one storage medium also stores encrypted 
index information correlating search information 50 
with portions of said encrypted database. 

15. A system as in claim 1 further including: 

a first memory means, operatively connected to said 
decrypting means, for storing said decrypted infor- 
mation; and 55 

a second memory means, operatively connected to 
said metering and communicating means and dif- 
ferent from said first memory means, for storing 
said metered usage. 

16. A secure database access system as in claim 1 60 
wherein said control means includes means for using 
said decrypted information and means for metering the 
duration over which at least one of: (a) said decrypting 
means decrypts said read encrypted information, (b) 
said using means uses said decrypted information and 65 
(c) said searching means searches said at least one data- 
base. 

17. A system as in claim 1 wherein: 
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said at least one database stored by said at least one 
storage medium is divided into plural discrete sub- 
divisions: 

said control means includes means for determining 
the subdivisions said selected portions are derived 
from; and 

said metering means includes means for telecom- 
municating signals indicating said determined sub- 
divisions. 

18. A system as in claim 1 wherein said control means 
measures the duration of usage of said decrypted infor- 
mation, and wherein said metering means includes 
means for storing said measured duration. 

19. A system as in claim 1 wherein said control means 
stores said identifications and/or measurements, said 
control means including means for inhibiting said de- 
crypting means from further decrypting said database 
whenever said memory device becomes filled and 
means for resetting said memory device in response to 
said certain information received from said distant loca- 
tion. 

20. A secure data base access system comprising: 

at least one storage medium storing at least one tex- 
tual database component and at least one index 
associated with said component; 

input means for providing database index search cri- 
teria in response to user input; 

searching means connected to said at least one stor- 
age medium and to said input means for searching 
said database, including reading means for refer- 
encing said index based on said search criteria, for 
identifying portions of said database in response to 
said index referencing, and for reading one of (a) all 
of said identified database portions, and (b) desired 
ones of said identified database portions from said 
at least one storage medium; and 

control means connected to said reading means for 
metering usage of information read by said reading 
means and for preventing said reading means from 
reading more than at least one predetermined per- 
centage of said at least one database in response to 
said meter usage, 

wherein: 

said at least one storage medium stores at least one 
scrambled directory of the location of the contents 
of at least one of (a) said at least one index, and (b) 
said at least one database as stored on said at least 
one medium; and 

said reading means includes means for descrambling 
said at least one scrambled directory and reading 
said identified database portions from said medium 
in a manner determined by said descrambled at 
least one directory. 

21. A secure data base access system comprising: 

at least one storage medium storing at least one tex- 
tual database in encrypted form, said at least one 
database including at least one collection of textual 
information, said at least one storage medium also 
storing index information, said index information 
correlating portions of said at least one encrypted 
database with search information; 

at least one host signal processor, operatively con- 
nected to said at least one storage medium, said at 
least one processor preprogrammed so as to: (a) 
accept search criteria in response to user input 
thereto, (b) search said index information, (c) iden- 
tify, in accordance with said search of index infor- 
mation, the portions of said at least one encrypted 
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database which satisfy said search criteria, and (d) 
read at least one of said identified encrypted data- 
base portions from said at least one storage me- 
dium; 

means for decrypting at least one read portion of said 5 
encrypted at least one database to produce corre- 
sponding decrypted information; and 

decoder control logic means, coupled to said host at 
least one processor, and said decrypting means, for 
measuring the percentage of at least one informa- 10 
tion collection decrypted by said decrypting 
means, said decoder control logic means including 
means for preventing decryption of more than at 
least one predetermined percentage of said at least 
one information collection. .15 

22. A method of providing information comprising 
the steps of: 

(1) providing at least one storage medium storing 
encrypted textual database information thereon; 
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(2) searching said encrypted information to identify at 20 prising the steps of: 



providing at least one random access storage medium 
having at least one database in encrypted form 
stored thereon and also having index information 
stored thereon, said index information correlating 
portions of said encrypted at least one database 
with unencrypted search information; 
generating search information; 
searching said index information for specific portions 
of said encrypted at least one database which sat- 
isfy said generated search information; 
decrypting at least one of said specific portions of said 
encrypted at least one database to produce corre- 
sponding decrypted information; 
measuring the quantity of information decrypted by 

said decrypting step; and 
inhibiting said decrypting step from decrypting more 
than a certain percentage of said at least one data- 
base in response to said measured quantity. 
29. A method of securing access to a database corn- 



least one portion of said encrypted information; 

(3) reading at least one of said identified portions 
from said at least one storage medium; 

(4) decrypting at least one of said read portions; 

(5) metering the usage of portions decrypted by de- 25 
crypting step; and 

(6) calculating a usage fee in response to said mea- 
sured usage. 

23. A method as in claim 22 wherein said metering 
step (5) includes the step of measuring the quantity of 30 
information decrypted by said decrypting step. 

24. A method as in claim 22 wherein: 

said at least one storage medium stores said encrypted 
information in blocks of predetermined length; and 

said metering step includes the step of counting the 35 
number of said blocks of information decrypted by 
said decrypting step. 

25. A method as in claim 22 wherein said metering 
step includes the step of determining the time at which 
said decrypting step decrypts said information. 40 

26. A method as in claim 22 wherein: 

said at least one storage medium stores plural discrete 

collections of encrypted information; 
said method further includes the step of selecting at 

least one of said plurality collections; and 45 
said metering step includes the step of storing signals 

indicating the usage of said selected at least one 

collection. 

27. A method of accessing a database comprising the 
steps of: 50 

storing encrypted text database information in digital 
form on a random access nonvolatile storage de- 
vice; 

searching for and retrieving portions of said stored 
database based on search criteria at least in part 55 
determined by user input; 

determining the quantity of one of (a) all of said re- 
trieved database portions and (b) only desired ones 
of said retrieved database portions ready said 
searching and retrieving step; 60 

metering information representing said determined 
quantity and storing said metered information in a 
further non-volatile storage device different from 
said first-mentioned storage device; and 

periodically conveying said stored quantity-repre- 65 
senting information to a location remote thereto. 

28. A method of securing access to a database com- 
prising the steps of: 



providing a random access mass storage means hav- 
ing at least one database in encrypted form stored 
thereon and also having index information correlat- 
ing portions of said at least one encrypted database 
with index information stored thereon; 
providing a database search request determined at 

least in part by user input; 
searching said index information from said storage 
means with a digital signal processing means of the 
type capable of displaying data and also capable of 
performing at least one of the additional functions 
of copying, storing, printing and communicating 
data and searching, in accordance with said index 
information, for specific portions of said at least 
one encrypted database which corresponds to said 
search information; 
decrypting at least one of said specific portions of said 
at least one encrypted database to produce corre- 
sponding decrypted information; 
selectively enabling further processing of said de- 
crypted information by at least one of said addi- 
tional functions; 
determining a cost for performing said displaying step 
in response to at least one first cost rate and at least 
one of (a) the quantity of information displayed and 
(b) the time duration over which at least one of said 
above-mentioned steps is performed; 
determining a further cost in response to at least one 
second cost rate different from said first rate and in 
response to one of: (a) the quantity of information 
which is further processed by said additional func- 
tions and (b) the time duration of which at least one 
of the said additional functions is performed; and 
storing at least one of said determined costs. 
30. A method of securing access to a database com- 
prising the steps of: 
providing a random access mass storage means hav- 
ing at least one database in encrypted form stored 
thereon and also having index information correlat- 
ing portions of said at least one encrypted database 
with index information stored thereon; 
providing a -database search request determined at 

least in part by user input; 
searching said index information on said storage 
means with a digital signal processing means of the 
type capable of displaying data and also capable of 
performing at least one of the additional functions 
of copying, storing, printing and communicating 
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data and searching, in accordance with said index 
information, for specific portions of said at least 
one encrypted database which correspond to said 
search information; 

decrypting at least one of said specific portions of said 5 
at least one encrypted database to produce corre- 
sponding decrypted information; 

restricting use of at least one of said specific portions 
of said decrypted information to display only and 
preventing performance of said additional func- 10 
tions with respect to said specific portions; 

determining at least one characteristic identifying 
said information decrypted by said decrypting step; 
and 

storing said determined characteristic. 15 

31. A method as in claim 30 wherein said method 
further includes selectively performing at least one of 
printing, storing, copying and communicating portions 
of the decrypted information restricted to display only 
by said restricting step. 20 

32. 'A method as in any of claims 30 and 29 further 
including the following steps: 

measuring the quantity of information decrypted by 

said decrypting step; and 
storing said measured quantity information. 25 

33. A method as in any of claims 30 and 29 wherein: 
said at least one database stored by said at least one 

storage medium is divided into plural discrete sub- 
divisions; 

said method further includes determining the subdivi- 30 
sions said selected portions are derived from; and 

said storing step includes storing signals representing 
said determined subdivisions. 

34. A method as in claim 30 wherein said displaying 
and preventing step includes the steps of: 35 

further processing of said decrypted information by 
at least one of printing, storing, copying and com- 
municating said decrypted information; 

calculating a first cost in response to a first cost rate 
and also in response to the time duration over 40 
which said displaying step is performed; 

calculating a second cost for performing said further 
processing step in response to a second cost rate 
' different from said first rate and in response to at 
least one of (a) the quantity of information further 45 
processed, and (b) the time duration said informa- 
tion is further processed; and 

storing said calculated first and second calculated 
costs. 

35. A method as in claim 22 wherein said method 50 
further includes the step of using said decrypted infor- 
mation and said metering step includes the step of deter- 
mining the time duration over which at least one of (a) 
said searching step searches said information, (b) said 
reading step reads said information, (c) said decrypting 55 
step decrypts said read portion, and (d) said using step 
uses said information. 

36. A method as in claim 28 wherein: 

said searching step comprises the following steps: 

(a) inputting search criteria determined at least in 60 
part in response to user input, 

(b) referencing at least one index stored on said at 
least one storage medium and associated with 
said selected at least one database and searching 
said at least one index for index entries corre- 65 
sponding to said inputted search criteria, 

(c) identifying database portions which correspond 
to said inputted search criteria, and 



28 

(d) selecting a subset of said identified database 
portions; and 

said method further includes reading, from said at 
least one storage medium, said selected database 
portions. 

37. A method as in claim 30 wherein: 

said searching step comprises the following steps: 

(a) inputting search criteria determined at least in 
partial response to user input, 

(b) searching said index information for at least one 
index entry corresponding to said inputted 
search criteria, 

(c) identifying at least one index entry which corre- 
sponds to said inputted search criteria, and 

(d) selecting a subset of said at least one identified 
index entry; and 

said reading and decrypting step includes reading 
from said storage means those at least one database 
portions corresponding to said selected subset of at 
least-one identified index entry and decrypting said 
read at least one database portion. 

38. A computer system comprising: 

memory means for storing at least one characterized 
of database usage; and 

signal processing means, operatively connected to 
said memory means and also operatively connected 
to at least one database including at least one en- 
crypted textual component and associated index 

. information, for performing the following func- 
tions; 

searching said at least one database component in 
response to search criteria determined at least in 
part by user-input and retrieving at least one por- 
tion of said at least one textual database component 
which satisfies said search criteria; 

decrypting said at least one retrieved portion of said 
at least one textual database component and pro- 
ducing a stream of signals corresponding to a de- 
crypted version of said retrieved portions, 

processing a portion of said signal stream in a first 
manner, 

processing a portion of said signal stream in a second 
manner different from said first manner, and 

storing in said memory means at least one of (a) the 
quantity of signals processed and (b) the time dura- 
tion over which at least one of said first manner 
processing step and said second manner processing 
step is performed. 

39. A method of accessing at least one database com- 
prising the steps of: 

storing text database information on a random access 
storage device; 

searching for at least one portion of said stored at 
least one database based on search criteria deter- 
mined at least in part by user input; 

retrieving at least one portion located by said search- 
ing step; 

using said retrieved at least one portion, 

determining a time duration corresponding to at least 
one of said searching and using steps; 

metering information representing said determined 
time duration and storing said metered information 
in a further storage device different from said first- 
mentioned storage device; and 

conveying said stored quantity-representing informa- 
tion to a location remote thereto. 

40. A database access system comprising: 
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storage medium means for storing at least one en- input means for providing database index search cri- 

crypted textual database and at least one index teria in response to user input; 

associated with and corresponding to said at least searching means operatively connected to said at 

one encrypted textual database; least one storage medium and to said input means 

memory means for storing information representing 5 for searching said database, including means for 

at least one database usage ceiling; referencing at least one index based on said search 

first input means operatively connected to said mem- criteria, for identifying portions of said encrypted 

ory means for updating said stored at least one at least one database in response to said index refer- 

database usage ceiling; encing, and for reading one of (a) all of said identi- 

further input means for generating database index 10 fied database portions, and (b) desired ones of said 

search criteria in response to user input; identified database portions from said at least one 

searching and retrieving means, operatively con- storage medium; 
nected to said storage medium means and to said means operatively connected to said searching 
input means, for searching said at least one data- means, for decrypting at least one portion of said 
base, for referencing said at least one index based 15 read encrypted information; and 
on said search criteria and for retrieving at least control means operatively connected to said decrypt- 
one portion of said encrypted at least one database in 6 means for metering usage of information de- 
from said storage medium means at least partially crypted by said decrypting means and for prevent- 
in response to said index referencing; ™8 decryption of more than a predetermined per- 

means operatively connected to said searching and 20 centage of said at least one database, 

retrieving means for decrypting said retrieved at ^ A s y stem 38 m claun 42 wh erein said control 

least one encrypted database portion; and means measures the number of contiguous blocks of said 

control means operatively connected to said decrypt- te * tual ^tmatum decrypted by said decrypting means 

ing means and to said memory means for metering „. and Pf events sald . decrypting means from decrypting 

parameters of usage of information decrypted by 23 mo ?f than a certam nun * er of said contiguous blocks 

said decrypting means, for comparing said metered system " m claml « wherem control 

usage with said at least one corresponding database ^ measures the tune duration over which at least 

usage ceiling stored in said memory mea^s, and for ° ne ° f f^ 8 mea f P I0C *? S "J* f °nnat IO n, 

preventing further decrypting by^said decrypting 30 J*"* ^SdL ^£tr«L T« 

„„„„„ ., f„ ; j _„ S ° , . " 30 metering means mcludes means for storing said mea- 

means if said corresponding at least one database S ured time duration. 

usage ceding does not exceed said metered usage. 45 A . daim 42 wherein said rf 

41. A database access system comprising: means measures the duration of of said dec * 
storage medium means for storing at least one en- information 

crypted textual database and at least one index 35 « A stem „ in claim 42 wherein said meteri 

associated with and corresponding to said at least means includes means for storm said infonn * 

one encrypted textual database; tion 

memory means for storing information representing a 47 A system ^ in claim 42 where in: 

time of cessation of database usage; ... said stored encrypted information has logically- 
real time clock means for providing an indication of w related segments; and 

real time; said control means determines which logically- 
first input means operatively connected to said mem- related segmen t s said selected portions are associ- 

ory means for updating said cessation time; ated w ith 

further input means for generating database index 43. A syst em as in claim 42 wherein: 

search criteria in response to user input; 45 ^ medium stores plural textual databases; and 

searching and retrieving means, operatively con- said control means meters usage ofless than all of said 

nected to said storage medium means and to said databases. 

input means for searching said at least one data- 49. a system as in claim 42 wherein said control 

base, for referencing said at least one index based means comprises: 

on said search criteria and for retrieving at least 50 a physically separable non-volatile memory device; 

one portion of said at least one encrypted database and 

from said storage medium means at least partially monitoring means operatively connected to said de- 

in response to said index referencing; crypting means and also disengageably operatively 

means operatively connected to said searching and connected to said memory device, for measuring 
retrieving means for decrypting said retrieved at 55 the quantity of information decrypted by said de- 
least one encrypted database portion; and crypting means and for storing said measured quan- 

control means operatively connected to said decrypt- tity in said memory device, 

ing means, said real time clock means and said 50. A system as in claim 49 wherein said monitoring 

memory means for metering parameters of usage of means disables said decrypting means from operating 

information decrypted by said decrypting means, 60 unless said memory device is operatively engaged 

for comparing said real time with said stored cessa- thereto. 

tion time, and for preventing further decrypting'by 51. A system as in claim 49 wherein said control 

said decrypting means if said stored cessation time means comprises: 

is not later than said real time. memory means for storing usage information; 

42. A secure data base access system comprising: 65 monitoring means, operatively connected to said 
at least one storage medium storing at least one en- decrypting means and also operatively connected 

crypted textual database component and at least to said memory means, for metering at least one of 

one index associated with said component; (a) the quantity of information decrypted by said 



decrypting means, (b) an identification of a subset 
of information stored on said, medium containing 
said identified portions, and (c) duration of at least 
one of searching, identifying, decrypting, reading 
and using of said database portions, for generating 5 
signals indicating the result of said metering, and 
storing said generated signals in said memory 
means; and 

means operatively connected to said decrypting i 0 
means and to said memory means for preventing 
said decrypting means from decrypting informa- 
tion whenever said metered indicating signals are 
not successfully stored in said memory means. 

52. A system as in claim 42 wherein said control and 15 
communicating means includes; 

a memory; and 

monitoring means, operatively connected to said 
decrypting means and to a communications net- 
work, for monitoring the quantity of at least one of : 
(a) information decrypted by said decrypting 
means and (b) information identified by said 
searching means, for controlling said signal com- 
municating means to communicate an indication of 25 
said monitoring to a billing facility over said com- 
munications network. 

53. A system as in claim 42 wherein said monitoring 
means also determines identifying characteristics of at 
least one of (a) said decrypted portions (b) of said identi- 30 
fied portions and controls said signal communicating 
means to communicate said identifying characteristics 

to said billing facility. 

54. A system as in claim 42 wherein: ^ 
said at least one storage medium also stores unen- 
crypted index information correlating unencrypted 
search information with portions of said at least 
one encrypted database. 

55. A system as in claim 42 wherein: 40 
said at least one storage medium also stores encrypted 

index information correlating search information 
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with portions of said encrypted at least one data- 
base. 

56. A system as in claim 42 further including: 

a first memory means, operatively connected to said 
decrypting means, for storing said decrypted infor- 
mation; and 

a second memory means, operatively connected to 
said metering and communicating means and dif- 
ferent from said first memory means, for storing 
said metered usage. 

57. A secure database access system comprising: 

at least one storage medium storing at least one tex- 
tual database in encrypted form, said at least one 
database including at least one collection of textual 
information, said at least one storage medium also 
storing index information, said index information 
correlating portions of said at least one encrypted 
database with search information; 

at least one host signal processor, operatively con- 
nected to said at least one storage medium, said at 
least one processor preprogrammed so as to: (a) 
accept search criteria in response to user input 
thereto, (b) search said index information, (c) iden- 
tify, in accordance with said search of index infor- 
mation, the portions of said at least one encrypted 
database which satisfy said search criteria, and (d) 
reach at least one of said identified encrypted data- 
base portions from said at least one storage me- 
dium; 

means for decrypting at least one portion of said at 
least one encrypted database to produce corre- 
sponding decrypted information; and 

decoder control logic means, operatively coupled to 
said host processor and said decrypting means and 
adapted for operatively connecting to a telecom- 
munications network, for metering the usage of 
information decrypted by said decrypting means, 

wherein said decoder control logic means includes 
means for telecommunicating said metered usage 
over said telecommunications network to a remote 
location. 
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[57] ABSTRACT 

The base station of a wireless communications network 
determines what features a mobile station will support, then 
downloads information to the mobile station which will 
notify the mobile station of which network features are 
available and how they may be accessed in the local net- 
work. Specifically, the base station provides the features 
codes that are required to access the network features. The 
base station may also inquire into what features the mobile 
station supports. Each of these communications may take 
place over the combination of the Paging Channel/Access 
Channel, collectively, the Control Channel, or the Traffic 
Channel. With the downloaded information, the mobile 
station user may select a desired feature using the method to 
which he or she is accustomed, i.e., either by selecting a 
menu location or by entering a familiar sequence of key- 
strokes. The mobile station's internal processor converts the 
entered values into the feature codes corresponding to the 
selected features within the network. The process of down- 
loading the feature code information does not require the 
user's intervention, such that any conversion required from 
the user's familiar feature access process is transparent to 
the user. 

29 Claims, 3 Drawing Sheets 
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REMOTE FEATURE CODE PROGRAMMING 
FOR MOBILE STATIONS 

FIELD OF THE INVENTION 

This invention relates generally to programming of net- 5 
work feature codes in mobile stations, and more specifically 
for providing a user-transparent conversion of one or more 
of a set of network feature codes in a mobile station to 
facilitate use of network features which must be accessed 
using a different set of feature codes. 

BACKGROUND OF THE INVENTION 

Telephone service carriers, including both mobile cellular 
and PCS networks, provide a number of different features 15 
which may be used by a network subscriber at the subscrib- 
er's discretion. A non-exhaustive list of features which may 
be provided include Call Forwarding, Call Waiting, Calling 
Number Identification, Automatic Callback, Conference 
Calling, Message Waiting Notification, Call Encryption, 2 o 
Selective Call Acceptance, Voice Mail, Enhanced Vocoder, 
and Cost of Call Notification. Activation or deactivation of 
such features typically involves the completion of a 
sequence of keystrokes on the keypad to enter the "feature 
code", also known as a "vertical service code" or " VSC", for 2 5 
selecting or de-selecting the desired feature. The keystrokes 
may involve the entry of a numeric sequence preceded by 
the star key (*) and/or followed by the pound key (#), e.g., 
"*66#", or may involve the selection of a dedicated menu by 
pressing a "Menu" key followed by a one- or two-digit 30 
number, one or more soft keys, or by scrolling the menu 
screen. Even when a mobile unit has menu capability, the 
feature code value specific to the home network is com- 
monly a numeric sequence as above, with selection of the 
"Menu" key being sent as a star key to indicate a feature 35 
code. In this case, the feature code value is programmed 
upon activation of the feature to correspond to a particular 
menu location, and the actual feature code value is unknown 
to the user. 

While the network subscriber may become thoroughly 40 
familiar with the procedure for access feature codes within 
his or her home network and mobile phone, several obstacles 
to the optimal usage of such features exist as a result of the 
lack of standardization within the communications industry. 
These obstacles may appear because, for example, the 45 
feature code for any given feature may be different from one 
network to another, not all networks provide all features, and 
there is a large number of different types of telephones, 
many of which may not support such features, or which have 
their own pre-determined menu-based sequence for select- so 
ing feature codes. While these issues may pose little prac- 
tical difficulty for wire-based network subscribers, mobile 
phone users frequently travel between coverage areas of 
different network service providers and, thus, are likely to 
experience the loss of, or inability to control, a desired 55 
feature. Under current practices, the only way that a mobile 
user can determine whether his or her feature code matches 
the corresponding code for the visited network is to try it. If 
the entered value matches, an acknowledging tone or mes- 
sage will be received at the mobile unit. If the code does not 60 
match, a different tone or message will indicate an unsuc- 
cessful entry. While little may be done if a mobile user has 
entered an area covered by a visited network that simply 
does not offer a desired feature, the typical user does not 
want to go to the time and trouble if, even when the visited 65 
network provides the feature, the only way to control the 
feature is to request the assistance of that network's cus- 



tomer service representative. In addition to the problem of 
dealing with different feature codes used in visited networks, 
even if the mobile user is not traveling between networks, 
advances in technology and increased competition between 
service providers is resulting in the availability of new 
network features which must be enabled in the mobile 
stations of existing subscribers within the mobile's home 
network. 

FIG. 1 provides a diagram of the functional entities within 
a network to illustrate how feature codes are handled in a 
conventional wireless communications network. Generally, 
the network consists of the Mobile Station 100, the Base 
Station 200 and the switching system 300 (designated by 
dashed lines). Within switching system 300 is the Mobile 
Switching Center (MSC) 302, for the first network, Home 
Location Register (HLR) 304 and Visitor Location Register 
(VLR) 306. MSC 310 is a second Mobile Switching Center 
corresponding to the home network for Mobile Station 100, 
which is connected to MSC 302 via conventional wired- 
based connection for communicating information regarding 
MS 100 to the visited network. Under current feature code 
implementation procedures, once MSC 302 receives a "*" or 
"Menu" input ("Menu" will be seen by the MSC as a star) 
from MS 100 (via BS 200), it transfers the information to 
HLR 304, which stores and manages subscriptions, and 
contains permanent subscriber information. If MS 100 is 
operating within its home network, HLR 304 will recognize 
the feature code entered by the mobile user and provide the 
requested response. If MS 100 is outside of its home 
network, MSC 302 will transfer information about the 
mobile station to VLR 304, which contains temporary 
information needed by MSC 302 to serve visiting mobile 
stations. If a star key ("*") is pressed followed by two digits 
to activate a feature code by a visiting mobile station, the 
message will still be processed through HLR 304. Using 
procedures established under the IS-41 standard for inter- 
network communications, MSC 310 is contacted by MSC 
302 once it is determined that MS 100 is outside of its home 
network to provide the information necessary for MSC 302 
to communicate with MS 100. Since HLR 304 processes 
feature codes under current procedures, and since it contains 
only information regarding the system's own subscribers, it 
is unable to process feature codes from visiting mobile 
stations if the requested feature code value differs from its 
own value. Attempts by a visiting mobile station to access a 
feature code with a different value, or a feature not supported 
by the visited system, will be met with a busy signal, or some 
other indication that the requested feature is unavailable. 

Industry efforts are being made to standardize certain 
feature codes and the requirements for activating them under 
Telecommunications Industry Association/Electronics 
Industries Association Interim Standard 52-A (TLA/EIA/IS- 
52-A), and/or INC 96-0802-015 ("Vertical Service Code 
Assignment Guidelines"), incorporated herein by reference, 
which will be of assistance with new networks and new 
mobile units once the standardization is completed. Delays 
in implementation of the new standardized feature codes in 
existing networks are likely to be on the order of two or three 
years from Final Closure of the issue, which occurred in 
August 1996. 

The newer standards provide for a shift of the processing 
of feature codes to the Mobile Switching Center, which, 
while having the advantage of removing the previous limi- 
tation created by handling the feature codes in the Home 
Location Register, still requires standardization of the fea- 
ture codes amongst all mobile phone manufacturers in order 
to make sure that every mobile station uses the feature code 
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recognized by the MSCs. Because many mobile phone The downloaded information may contain a list of net- 
manufacturers have developed their own systems and work features that are supported by the visited network and 
preferences, it is unlikely that a consensus could be achieved how those features may be accessed. This access informa- 
for adopting a single menu standard or a single numeric tion ma y be stored in the mobile station's memory as 
sequence for accessing feature codes from every mobile 5 Reverse Channel Information Records, or in some other 
phone, regardless of manufacturer. Further, new features are memory location to which the mobile station's processor 
certain to be added in the future, which will need to be mav refer t0 translate entries from the mobile station's 
implemented in existing networks and subscriber mobile menu > or other feature ^ ke y in g sequences, into 
units. Accordingly, the need remains for means to enable the system-specific feature codes for the visited network, 
mobile users to readily access network features across 10 when the mobile ^ selects a feature to activate or 
multiple networks without requiring the user to learn addi- deactivate, the sequence of keystrokes with which he or she 
tional feature codes. ^ familiar, or which is selected via the menu display of the 

mobile unit, is entered. The information for the selected 

SUMMARY OF THE INVENTION feature which is stored in the Reverse Channel Information 

j 5 Records is then transmitted to the base station with an 

It is an advantage of the present invention to provide appropriate reverse channel message, such as a Page 

means for allowing a mobile user to access network features Response Message, Status Message, or Flash with Informa- 

without requiring knowledge of the network's specific fea- tion Message, along with a request for acknowledgment, 

hire codes. wnen the mobile user wishes to activate or deactivate the 

It is another advantage of the present invention to provide 2Q feature. The base station responds indicating activation or 

means for programming a mobile station with information to deactivation of the selected feature. If the visited network 

provide a user-transparent conversion of a first set of net- does not support a particular feature, the base station will 

work feature codes to a different, second set of feature codes respond with an indication of that fact, causing a busy signal 

which are recognized by the mobile station. or some other tone to be heard by the user. If the mobile unit 

In an exemplary embodiment, the method for remote 2 5 nas a display screen, information the phrase "feature not 
feature code programming first registers a visiting mobile available" may be displayed following entry of the key- 
station using the standard registration procedures provided strokes for that feature. 

for in the established industry standards to notify the visited When new features become available within a network, 
network base station of the mobile station's presence. even within the mobile station's home network, the network 
According to these standards, which include the TIA/EIA/ 30 base station can download the information required to access 
IS-95 and ANSI-J-008 standards, when a mobile user visits the new feature using the same procedure. Similarly, if the 
a network, registration procedures are used to enable the home network changes its feature code values, for example, 
visited network to identify the mobile unit network connec- if it adopts a standardized set of feature code values, the 
tion and paging purposes, and the mobile station's home home network will be able to provide this information to the 
network, for billing purposes. Once registered, the base 35 mobile station without requiring the mobile user to releam 
station will download information to the mobile station an entire set of feature codes. If the mobile unit does not 
which will notify the mobile station of which network have a display, external notification of the new feature 
features are available and how they may be accessed in the should be provided to the subscriber, e.g., by mail. If the 
local network. The base station may also inquire into what mobile unit has a display screen, the information down- 
features the mobile station supports. Each of these commu- 40 loaded can include a message for display to the user to notify 
nications may take place over the combination of the Paging the user of the new feature and how it may be accessed. For 
Channel/Access Channel, collectively, the Control Channel, mobile phones with menu displays, the new feature may be 
or the Traffic Channel. With the downloaded information, added to the menu, and may be accessed by stepping or 
the mobile station user may select a desired feature using the scrolling through the menu. 

method to which he or she is accustomed, i.e., either by 45 Downloading of the local feature codes does not require 

selecting a menu location or by entering a familiar sequence access of the mobile unit's protected memory, and the 

of keystrokes. The mobile station's internal processor con- information can be exchanged as part of standard registra- 

verts the entered values into the feature codes corresponding tion procedures, over the Control Channel, or over the 

to the selected features within the network. The process of Traffic Channel. This procedure may be used regardless of 

downloading the feature code information does not require 50 whether the mobile unit is located in its home network or in 

the user's intervention, such that any conversion required a visited network. Since the local feature codes may be 

from the user's familiar feature access process is transparent changed frequently if the mobile user travels often, and since 

to the user. the information can be downloaded/refreshed during every 

The downloading step for providing a new set of feature activation procedure or paging sequence, if necessary, the 

codes may be included in any of a number of different 55 local network's feature codes may be stored in the phone's 

established messages. For example, using the Control temporary memory, much like a list of recent calls. 

Channel, the base station may include the feature code data Where a feature is subject to a subscription charge and 

in either the Mobile Station Registered Message, when the requires provisioning, for example, a high quality vocoder 

mobile station attempts to originate a call after registration, option, information regarding support of such a feature, 

or in some other forward channel message, such as a Page 60 selection of the appropriate feature code, and acceptance of 

Message. The process may also occur over the Traffic billing terms may preferably be communicated on the Traffic 

Channel, for example, in a Data Burst Message, or can be Channel due to that fact that a number of messages and 

done using a combination of messages communicated over responses may need to occur for the transaction. During a 

the Control and Traffic Channels, such as in the Over-the-Air combination of communications over the Control and Traffic 

Parameter Administration (OTAPA) method disclosed in 65 Channels, the transactions can occur for notifying the user of 

co-pending application Ser. No. 08/837,970, filed Apr. 15, a surcharge, responding with acceptance of the surcharge, 

1997, of the present inventor. and activation of the feature if accepted by the user. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Understanding of the present invention will be facilitated 
by consideration of the following detailed description of 
preferred embodiments of the present invention taken in 
conjunction with the accompanying drawings, in which like 
numerals refer to like parts, and in which: 

FIG. 1 is a block diagram of an exemplary prior art 
communications network including a mobile station, a base 
station and a switching system; 

FIG. 2 is a block diagram of an exemplary mobile phone 
receiver; 

FIG. 3 is a diagrammatic view of a mobile unit handset 
with a menu display; 

FIG. 4 is a diagram of an exemplary call flow for changing 
a Feature Code List according to one embodiment of the 
present invention; and 

FIG. 5 is a diagram of an exemplary call flow for changing 
a feature code for a provisioned feature according to another 
embodiment of the invention. 

DETAILED DESCRIPTION OF A PREFERRED 
EMBODIMENT 
The following detailed description utilizes a number of 
acronyms which are generally well known in the art. While 
definitions are typically provided with the first instance of 
each acronym, for convenience, Table 1 below provides a 
list of the acronyms and abbreviations used herein along 
with their respective definitions. 

TABLE 1 



ACRONYM DEFINITION 



ANSI American National Standards Institute 

BS Base Station 

CDMA Code Division Multiple Access 

EF Extended Feature 

EFCC Extended Feature Change Code 

EIA Electronics Industries Association 

ESN Electronic Serial Number 

HLR Home Location Register 

INC Industry Numbering Committee 

IMSI International Mobile Station Identity 

IS Interim Standard 

MIN Mobile Identification Number 

MS Mobile Station 

MSC Mobile Switching Center 

NID Network Identification 

OTAPA Over-the-Air Parameter Administration 

OTASP Over-the-Air Service Provisioning 

RAM Random Access Memory 

SID System Identification 

SMS Short Message Service 

TIA Telecommunications Industry Association 

TSB Technical Service Bulletin 

VLR Visitor Location Register 

VSC Vertical Service Code 



It should be noted the font variations within the specifi- 
cation and claims, particularly italicized text and text in all 
capital letters, reflect the formats established according to 
the various standards which are applicable to wireless 
communications, e.g., IS-95. 

Referring to FIG. 2, a conventional mobile phone 
receiver, which is generally designated by reference numeral 
100, typically comprises an antenna 10 for receiving call 
signals. The received signals are provided to a receiver and 
a demodulator circuit 20 and the resulting digital signal is 
fed to a microcontroller 30. Microcontroller 30 comprises a 
decoder 32, a processor 34, and an internal RAM 36. The 
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digital signal is decoded by the decoder 32 and processed by 
processor 34, which reads from or writes to internal RAM 
36. Memory storage for optional features, messages, and 
other data is provided by RAM 40. The user can enter data 

5 into processor 34 via user input circuitry 60. 

A non-volatile memory 50 is coupled to processor 34 for 
storage of information necessary for the operation of mobile 
phone receiver 100. The memory can be an electrically 
erasable programmable read only memory (EEPROM), a 

10 battery backed up memory device, or a similar memory 
device which retains information even when power is not 
applied to the mobile phone. Processor 34 accesses infor- 
mation such as options for various features from non- 
volatile memory 50 during operation, and can alter infor- 

15 mation in the memory 50 by reprogramming in accordance 
with the present invention. 

The following detailed description specifically refers to 
the protocol and procedures for operating a CDMA network 
conforming with the TIA/EIA/IS-95 standard (which is 

20 incorporated herein by reference), however, it will be appar- 
ent to those skilled in the art that by substituting the 
corresponding protocol and processes for various analog or 
PCS network architectures, the inventive feature code pro- 
gramming method may be similarly implemented in other 

25 wireless communications networks. 

Stored within the programmable non-volatile memory 50 
of mobile phone receiver 100 is the phone's identifying 
information, including its mobile identification number 

30 (MIN for analog; IMSI for CDMA), electronic serial number 
(ESN), network identification (NID), system identification 
(SID), home registration indicator (HOME 13 REG), along 
with other information which will allow the network base 
station 200 to locate, page, and determine the characteristics 

35 and capabilities of the mobile station. According to IS-95 
procedures, certain of this information must be changed 
within the mobile station's memory in order for the mobile 
station to operate within a visited network. 

Whenever the mobile station enters the visited network, 

40 registration procedures are initiated. As is known in the art, 
the manner of initiation of registration procedures depends 
upon how the mobile station is set-up, and may be autono- 
mously initiated by time, distance, zone, powering up and/or 
powering down the unit while the mobile unit is roaming. 

45 Autonomous registration procedures may take place when 
the mobile unit is active, while on the Traffic Channel, or 
when it is in the Mobile Station Idle State, while the mobile 
unit monitors the Paging Channel, and does not require the 
user's intervention. Other registration procedures occur 

50 when the mobile station changes its stored parameters or 
when it enters a new system (Parameter-change 
registration), or when it receives messages from the base 
station over a Paging Channel or Traffic Channel. Generally, 
the autonomous registration procedures are directed toward 

55 preparing the mobile station for communicating with the 
base station so that registration can be completed once the 
mobile station is activated for communicating on a Traffic 
Channel. 

Continuing the registration process as provided under 
60 standardized procedures, a network base station sends sys- 
tem overhead messages on the Paging Channel to provide 
the mobile station with the information it needs to operate 
with the base station. Included within the overhead mes- 
sages is the identifying and operating information for the 
65 base station. A mobile station in the Mobile Station Idle 
State monitors the Paging Channels in accordance with 
standardized procedures. Upon receipt of a Page Message 
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containing the identifying and operating information for the procedure for Over-The-Air Parameter Administration 

base station, the mobile station compares the configuration (OTAPA). A difference between the OTAPA and OTASP 

message sequence number to the corresponding number procedures is that initiation of the OTAPA procedure does 

stored in its memory. If the comparison results in a match, no t require the intervention of the mobile user, 

the system parameters are the same as those already stored, c -p. m „u;i„ „u„„„ » a :u 

, f, f ., .... ,, 1C 1 . . ,' 5 Ine mobile phone is pre-programmed with a service 

and the mobile station ignores the message. If a mismatch c , . ... r b , , , ., . 

results, the mobile station enters the Update Overhead option for changing or addmg extended subscriber features 

Information Substate and stores the appropriate parameters wmc u h m ?J udes ^§™t of an Extended Feature (EF) 

as Reverse Channel Information Records. Detection of a number The mobile phone will also have one or more 

mismatch at this point may be used to trigger the procedure in extended features change codes (EFCCs) in its memory. The 

for downloading a new set of feature codes from the base 10 netwo ) rk > whether 11 18 the moblle ' s home network or a 

station to the mobile station. The new set of feature codes Vlsl ' ed network, possesses means for determining whether a 

may be included in this message in one embodiment of the moblle P hone 15 OTAPA capable. Note that the visited 

programming method. The mobile station transmits a Page network m ^ establlsh OTAPA support for a particular 

Response Message to confirm the downloading of the 1C mobile station using IS-41 communications with the home 

updated parameters and to notify the base station that the 15 network ' bovver, protocol for the transfer of such infor- 

mobile station subscribes to certain network features. matlon w11 need t0 be added t0 the IS " 41 standard 

In another embodiment, rather than downloading the In the OTAPA procedure, the network base station sends 
feature codes over the Paging Channel, the procedure con- a General Pa S e Message to the mobile phone using the EF 
tinues. Still on the Paging Channel, the base station sends a 20 number. After first verifying its identity using the standard- 
Channel Assignment Message directing the mobile station to Ked Authentication process, if the mobile phone has OTAPA 
move to an assigned Traffic Channel. The mobile station capability, it responds with a Page Response Message, 
processes the Channel Assignment Message and sets up the indicating support for the EF by sending the EF number. If 
designated Traffic Channel according to IS-95 procedures. the mobile station does not support the option, the response 
The base station transmits a Status Request Message inquir- 25 ^ indicate that the option is not available. Once the 
ing into the features supported by the mobile station, to presence of the option is confirmed, the base station trans- 
which the mobile station responds with a Status Response mits a Channel Assignment Message, telling the mobile 
Message to identify the supported features. (Note that this station to proceed to the Traffic Channel. In order to prevent 
exchange may occur even if the mobile station is in the unauthorized access to the mobile user's billing records, it 
Conversation Substate.) 30 may be desirable to use the Signaling Message Encryption 

During any one of the above Forward Channel (SME). 
communications, the base station can include a message Once the mobile station is on the Traffic Channel, an 
containing the corresponding feature codes that are to be OTASP Data Message is sent that an additional fee is 
used in the visited network. These new feature codes are charged for the use of the feature and requesting acknowl- 
stored in the mobile station's memory as additional Reverse 35 edgment of acceptance. If accepted, a second OTASP Data 
Channel Information Records. The mobile station's proces- Message is sent containing a Extended Feature Change Code 
sor will then transmit these new feature codes in place of the (EFCC). If the EFCC matches the EFCC for the mobile 
previously-programmed feature codes whenever the user station, it is verified by the mobile unit, after which it may 
wishes to access a particular feature. Thereafter, when the be used to unlock the mobile station, update the feature 
mobile user attempts to activate or deactivate a particular 40 code(s) and store the updated feature code(s) into the 
network feature, entry of the keystroke sequence to which phone's memory. After verification of the programmed data 
the user is accustomed will automatically cause the mobile in accordance with OTASP processing, the process is ter- 
station to transmit the appropriate system-specific feature minated. If the user refuses the additional billing, no down- 
code to the base station. loading will occur. A number of different EFCCs may be 

Alternatively, rather than requiring an additional inquiry 45 used for diff erent feature codes so that the user may elect the 

into the supported feature codes, since the base station has feature c° des individually to avoid being billed for access to 

already ascertained that the mobile station is likely to have a11 possible optional extended features when only one is 

a different set of feature codes based upon the mismatch of desired. 

other system and network identities during registration, the As specified in the IS-683 standards, delivery of OTASP 
new feature code information may be automatically trans- 50 Data Messages does not require sequential delivery of 
mitted from the base station along with the Mobile Station messages by the layer 2 protocol because OTASP proce- 
Registered Message. This message, which includes the dures ensure that only one OTASP Data Message is out- 
parameters for communicating with the base station, will standing at any time. Therefore, a Data Burst Message 
store the new system and network information into the (OTASP BURST_TYPE) may be used in accordance with 
mobile's memory. 55 TTA/EIA/58, "Administration of Parameter Value Assign- 
In an embodiment in which the mobile user subscribes to ments for TIA/EIA Wideband Spectrum Standards". Data 
a network feature for which a subscription fee is charged, Burst Messages may also be used on the Control Channel 
such as enhanced vocoder capability, voice mail, voice (Paging/ Access Channel) per IS-95 specifications, 
dialing, or conference calling, the feature must be Using a similar procedure, a visited network will need to 
provisioned, when initially subscribed to, when the mobile 60 confirm that the visiting mobile user is willing to pay for use 
user wishes to utilize the feature outside of his or her home of a feature within the visited network when the mobile user 
network, and/or when the subscribed features are changed. can use the same feature in his or her home network without 
Access to the feature, hereinafter referred to as an "extended additional charge. For example, call forwarding may be 
feature", may be provided using the over-the-air program- provided at no extra charge by some network providers, 
ming protocol and procedures which support the Over-The- 65 while others add a surcharge for the service. In this case, the 
Air Service Provisioning (OTASP) feature in accordance visited network base station will send a message to the 
with established industry standards (TIA/EIA/IS-683) in a mobile station that a selected feature can be accessed only 
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with payment of a toll by causing a message to be displayed Waiting, and "*67#" (+"Send") for deactivating Call 

on the display of the mobile station such as "Toll for Waiting, the mobile user will press the four keys in the 

Feature". The base station will then wait for confirmation proper sequence. To continue the example, the visited net- 

from the mobile station before downloading the feature code work's feature codes for Call Waiting are "*55#" and 

which will allow activation of the feature. 5 "*56#" for activation and deactivation, respectively. Fol- 

It should be noted that the system-specific feature code lowing the downloading of the correct system parameters, 

information need not be included within system overhead including the system-specific feature codes of the visited 

information, nor is it limited to inclusion in a System network, the mobile station's processor will cause the 

Parameter Message, Mobile Station Registered Message, mobile station to transmit a "*55#", even when the user has 

OTASP Data Message, or Data Burst Message. These mes- ™ pressed "*66#". 

sages are exemplary only. The system-specific feature code Where a feature code is entered preceding a phone 
information can be included in any message, whether trans- number, for example, for Call Forwarding, it may be desir- 
mitted over a Paging Channel or a Traffic Channel, which is able to limit the translation of feature codes to a specific 
capable of initiating a downloading operation to the mobile number of digits following the "*", so that the subsequent 
station when a discrepancy exists between certain system 15 phone number is not also inadvertently converted. Again 
operating parameters, in this case, the feature codes, and the using the situation where the feature codes are selected by a 
access-enabling parameters stored within the mobile station. two digit number, in the home network, Call Forwarding 
Whichever message type is used, an appropriate header or may be activated by entering "*44*555-4444#" (+"Send"), 
data field will need to be provided to designate the nature of where 555-4444 is the phone number. In the visited network, 
the message as relating to feature code updating. As in the 20 the feature code to activate Call Forwarding may be "*55". 
case of any new feature in standardized systems and data To avoid the possibility of conversion of the phone number 
formats, addition of new system overhead information may as well as the feature code, the processor would look only at 
require changes to existing IS-41 (Network Specification) the first two digits entered following the star key. 
specified messages, or other new messages may need to be i n a sec0 nd embodiment of the method for remote pro- 
defined by the standards organizations. Initiating such 25 gramming of feature codes, the mobile station completes the 
changes is an administrative task that will be readily appar- registration procedure in the visited network, making it 
ent to those in the art. capable of communicating with the local base station. 

To provide an example of the invisible nature of the Rather than automatically downloading the local feature 

feature code translation, FIG. 3 illustrates a Nokia® Model codes into the visiting mobile station's memory at the time 

2120 mobile phone. With the mobile phone initially in the 30 of, or in response to the initial activation of the mobile 

Idle State, the "Menu" soft key 300 is pressed followed by station within the network, the base station waits until it 

numerical keys "6" 302 and "5" 304 to select the "Call receives an Origination Message from the mobile station 

Waiting" feature. Alternatively, the user can press the over the Access Channel for a mobile-initiated call which 

"Menu" soft key 300, then step forward or backward includes an indication, i.e., the star key ("*"), that the mobile 

through the list of feature by pressing the "up arrow" 306 or 35 user wishes to access a feature, e.g., Call Forwarding. If the 

"down arrow" 308 on key 310. particular feature code value is not recognized by the base 

Once the desired function is displayed on display screen station, it may respond over the Paging Channel, or on the 

312, the user then presses the "Select" soft key 314. To Traffic Channel after providing a channel assignment, with 

activate the Call Waiting feature, the user presses "up arrow" information containing the local feature code values for 

306. To deactivate Call Waiting, the user presses "down downloading into the mobile station's memory. The proces- 

arrow" 308. sor within the mobile station determines the correct local 

Due to the differences between mobile handsets from feature code and responds with an Origination Continuation 

different manufacturers, keys which perform a similar func- Message to activate the Call Forwarding feature by 

tion may be labeled differently. For example, some manu- 45 re-sending the message using the correct feature code values 

facturers will caU their equivalent of the Nokia® "Menu" for the visited network. In this embodiment, information 

key a "Feature" key. Other manufacturers may use different regarding local feature code values is provided only when 

combinations of soft keys and hard keys. With the present access t0 a feature 1S requested by the mobile user. Because 

method of remotely programming feature codes, the mobile the downloading of the feature code information is triggered 

user can utilize his or her preferred format (as selected based 50 b V the ' ec l uest for access t0 a feature > the mobile "« r L need 

upon the chosen make of mobile handset), use the feature not Perform any additional steps beyond that to which he or 

code selection method to which he or she is accustomed, and she is au " eadv customed, with the conversion occurring 

still be able to access the desired feature regardless of how internally within the mobile station's processor, 

dissimilarly a visited network has its feature codes set up. FIG. 4 provides an exemplary flow diagram for accessing 

Referring briefly to FIG. 2, the preceding keystroke 5 5 a network-specific features code using a visiting mobile 

sequence comprises a user input via user input 60 to pro- station in a visited network. The following assumptions 

cessor 34. Using the system-specific feature code informa- apply: 

tion stored in memory (either non-volatile memory 50 or 1) The Mobile Station and Base Station each supports the 

RAM memory 40), processor 34 converts the selected Call Waiting feature without surcharge; 

feature into the appropriate feature code for the network 60 2) The Mobile Station's home network utilizes a different 

which is then transmitted to the base station for implemen- feature code for Call Waiting than is used by the visited 

tation (activation or deactivation). network in which the Base Station is located; and 

For mobile station handsets which do not have menu 3) The Mobile Station has already performed the initial 

display capability, features are typically selected by a press- steps for registration in the visited network, including 

ing a keystroke sequence designated by the mobile's home 65 updating overhead information, 

network. For example, if "*66#" (+"Send") is designated by Using the example provided in FIG. 3, the user wishes to 

the home network service provider for activating Call activate Call Waiting and enters "Menu", "6", "5", and 
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"Send". Mobile Station 100 detects a user initiated call 101 
which includes selection of a feature code (by depressing the 
"Menu" key) and sends an Origination Message 101 over 
Access Channel 150 to the visited network Base Station 200. 
Included in Origination Message 101 is the indication that a 5 
feature code is selected. Base Station 200 receives the 
message (Step 201), verifies the identity of the mobile 
station (step 202) and responds with a Mobile Station 
Registration Message 203 on the Paging Channel 160 which 
includes the new system-specific feature code values for the 10 
visited network. Mobile Station 100 processes the received 
new feature codes (step 103) and downloads the information 
into its memory (step 104). Processor 34 correlates the 
entered value ("Menu", "6", "5") with the system -specific 
feature code (*55) that was previously downloaded (step 15 
105) and sends an Origination Continuation Message 106 
which acknowledges the received information and includes 
the translated feature code value (*55). Base Station 200 
received the message (step 204) and responds with an 
Acknowledgment Message 205, acknowledging activation 20 
of the Call Waiting feature. The call is then released (step 
206). 

In this case, the mobile user did not have to enter any 
different feature codes since the Mobile Station's processor 
automatically and transparently converted the feature code 25 
to the correct value for communicating with the visited 
network. 

In a second exemplary call flow shown in FIG. 5, the 
feature to be selected is one which requires provisioning. 
The following assumptions apply: 30 

1) The Mobile Station and Base Station each supports the 
Enhanced Vocoder feature; 

2) The Mobile Station's is initially programmed to utilize 
a different feature code for Enhanced Vocoder than is 
used by the Base Station; and 35 

3) The Mobile Station is already registered with the Base 
Station. 

In FIG. 5, the Mobile Station is, again, generally desig- 
nated as 100 and the Base Station as 200. Mobile Station 100 
detects a user initiated call 110 which includes selection of 40 
a feature code (by depressing the star key) and sends an 
Origination Message 111 over Access Channel 150 to the 
visited network Base Station 200. Included in Origination 
Message 111 is the indication that a feature code is selected. 
Base Station 200 received the message (step 210) and sets up 45 
a Traffic Channel, then sends a Channel Assignment Mes- 
sage 211 on the Paging Channel 160. Mobile Station 100 
processes the Channel Assignment Message 211 and sets up 
the designated Traffic Channel 170 according to IS-95 
procedures (step 112). 50 

Base Station 200 sends a Data Burst Message 212 using 
OTASP BURST-TYPE fields which include information that 
the selected feature code is subject to a surcharge and a 
request for acceptance of the surcharge. Mobile Station 100 
processes Data Burst Message 212 and indicates to the user 55 
that acknowledgment of acceptance is required (step 113). 
The user enters his or her acceptance by pressing the 
appropriate key (step 114), which is transmitted over the 
Reverse Traffic Channel to Base Station 200 as Data Burst 
Message 115. Base Station 200 processes the acceptance of 60 
billing (step 213) and sends a second Data Burst Message 
214 including the EF number and the feature code for the 
Enhanced Vocoder feature. Mobile Station 100 processes 
Message 214 (step 116), downloading the feature code into 
its memory (step 117) and responds with Data Burst Mes- 65 
sage 118 requesting activation of the Enhanced Vocoder 
feature. Base Station 200 receives and processes the request 



proceeds with his or her conversation (step 119). 

In addition to its application to allowing a mobile station 
to access network features when visiting other networks, the 
procedure for remotely programming feature codes in a 
mobile station can also be used in the mobile station's home 
network when new features or made available, or if the 
network adopts a feature code standard which differs from 
its previously designated feature codes. Further, the remote 
programming feature is not limited to mobile telephones and 
voice communications devices, but may also include pagers 
and data communications devices, which also utilize net- 
work features and, thus, are subject to loss of features when 
traveling outside of a home network, or which will require 
updating when new network features become available. 

Other embodiments and modifications of the present 
invention will occur readily to those skilled in the art in view 
of these teachings. Therefore, this invention is to be limited 
only by the following claims, which include other embodi- 
ments and modifications when viewed in conjunction with 
the above specification and accompanying drawings. 

I claim: 

1. A method for accessing a plurality of network features 
enabled by a local set of feature codes using a mobile station 
having an original set of feature codes, the local set of 
feature codes being at least partially incompatible with the 
original set of feature codes, the method comprising: 

communicating between a network base station and the 
mobile station to register the mobile station with the 
network base station; 

transmitting the local set of feature codes from the base 
station to the mobile station; 

comparing the local set of feature codes with the original 
set of feature codes; 

if the local set of feature codes is at least partially 
incompatible with the original set of feature codes, 
storing the local set of feature codes within a memory 
of the mobile station; 

selecting an original feature code from the original set of 
feature codes corresponding to a desired network fea- 
ture of the plurality of network features using a user 
input on the mobile station; 

processing within the mobile station the selected original 
feature code to correspond to a local feature code for 
accessing the desired network feature; and 

transmitting from the mobile station to the base station the 
local feature code corresponding to the desired network 
feature. 

2. The method of claim 1, wherein the step of transmitting 
the local set of feature codes includes transmitting the local 
set of feature codes within a registration acknowledgment 



3. The method of claim 1, wherein the step of transmitting 
the local set of feature codes includes transmitting the local 
set of feature codes within a Paging Channel Message. 

4. The method of claim 1, wherein the step of transmitting 
the local set of feature codes includes transmitting the local 
set of feature codes within a Forward Traffic Channel 



5. The method of claim 4, wherein the Forward Traffic 
Channel Message is a Data Burst Message. 

6. A method for accessing a plurality of network features 
enabled by a first set of feature codes using a mobile station 
having a second set of feature codes corresponding to the 
network features, the first set of feature codes having at least 
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one feature code differing from the second set of feature 
codes, the method comprising: 

communicating between a network base station and the 
mobile station to register the mobile station with the 
network base station; 5 
transmitting the first set of feature codes from the base 

station to the mobile station; 
comparing the first set of feature codes with the second set 

of feature codes; 
if the first set of feature codes is different from the second io 
set of feature codes, storing the first set of feature codes 
within a memory of the mobile station; 
selecting a second feature code from the second set of 
feature codes corresponding to a provisioned network 
feature of the plurality of network features using a user 15 
input on the mobile station; 
processing within the mobile station the selected second 
feature code to correspond to a first feature code for 
accessing the provisioned network feature; 



12. The method of claim 8, wherein the step of transmit- 
ting the local set of feature codes includes transmitting the 
local set of feature codes within a Paging Channel Message. 

13. The method of claim 8, wherein the step of transmit- 
ting the local set of feature codes includes transmitting the 
local set of feature codes within a Forward Traffic Channel 



14. The method of claim 13, wherein the Forward Traffic 
Channel Message is a Data Burst Message. 

15. The method of claim 8, wherein one network feature 
of the one or more network features is a provisioned feature 
and further comprising the steps of transmitting from the 
base station a message requesting acceptance of a surcharge 
for the provisioned feature and awaiting acknowledgment of 
acceptance of the surcharge from the mobile station before 
transmitting a feature code corresponding to the provisioned 
feature. 

16. A method for administering a wireless communica- 
tions network comprising a base station and a plurality of 



transmitting from the mobile station to the base station the 20 mobile stations, each mobile station having an identity and 



t feature code corresponding to the provisioned 
network feature; 
transmitting from the base station a message requesting 
acceptance of a surcharge for the provisioned network 
feature; and 25 
awaiting acknowledgment of acceptance of the surcharge 
from the mobile station before transmitting a provi- 
sioned feature corresponding to the provisioned feature 

7. The method of claim 1, wherein the step of transmitting 3Q 
from the mobile station the local set of feature codes 
includes a request for acknowledgment of successful access- 
ing of the desired network feature. 

8. A method for remotely enabling a mobile station having 
an original set of feature codes to access at least one local set 3J 
of feature codes from a base station for use in selecting one 

or more network features of a local network, wherein the 
original set of feature codes is at least partially incompatible 
with the local set of feature codes, the method comprising: 

selecting an original feature code of the original set of 4Q 
feature codes corresponding to a desired network fea- 
ture of the one or more network features using a user 
input on the mobile station; 

transmitting the selected original feature code to the base 
station; 45 

transmitting from the base station the local set of feature 
codes; correlating within the mobile station the selected 
original feature code to a corresponding local feature 
code from the local set of feature codes; 

transmitting from the mobile station to the base station the 50 
corresponding local feature code for the desired net- 
work feature; and 

transmitting from the base station an acknowledgment of 
successful selection of the desired network feature. 

9. The method of claim 8, wherein the step of selecting an 55 
original feature code comprises entering a plurality of key- 
strokes at a keypad, the plurality of keystrokes including 
pressing a "Menu" key and selecting a pre-programmed 
menu location. 

10. The method of claim 8, wherein the step of selecting 60 
an original feature code comprises entering a plurality of 
keystrokes at a keypad, the plurality of keystrokes including 
pressing a "star" key followed by at least one numeric key. 

11. The method of claim 8, wherein the step of transmit- 
ting the local set of feature codes includes transmitting the 65 
local set of feature codes within a registration acknowledg- 
ment message. 



of pre-determined selectable feature codes for access- 
ing one or more network features, wherein a user of the 
mobile station is not required to initiate a procedure for 
changing the set of pre-determined selectable feature codes 
to a plurality of new feature codes, the method comprising: 
programming the mobile station with a feature code 
change option and at least one feature code change 
number for permitting over-the-air provisioning of net- 
work features; 
when provisioning of a network feature is requested by 
the user of the mobile station, transmitting a Page 
Message from a base station to the mobile station, the 
Page Message including a request to verify the identity 
of the mobile phone and a first data field for the feature 
code change option; 
receiving a Page Response Message from the mobile 
phone to the base station including the identity of the 
mobile phone; 
transmitting a Channel Assignment Message from the 
base station to the mobile phone, the Channel Assign- 
ment Message instructing the mobile phone to set up a 
traffic channel; 
transmitting a Data Burst Message from the base station 
to the mobile phone instructing the mobile phone to 
enter an over-the-air service provisioning process; 
transmitting the at least one feature code change number 
corresponding to the requested network feature from 
the base station to the mobile phone; 
transmitting from the mobile phone to the base station a 
response verifying the at least one feature code change 
number; 

downloading a new feature code of said plurality of new 
feature codes for accessing the requested network fea- 
ture from the base station to the mobile phone, the new 
feature code not included in the set of pre-determined 
selectable feature codes; 

transmitting a message from the base station to the mobile 
phone for requesting activation of the requested net- 
work feature; and 

acknowledging activation of the requested network fea- 
ture. 

17. The method of claim 16, further comprising the steps 
of transmitting from the base station a message requesting 
acceptance of a surcharge for the requested network feature 
and awaiting acknowledgment of acceptance of the sur- 
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charge from the mobile station before transmitting a feature 
code corresponding to the requested network feature. 

18. Amobile phone having means for accessing a local set 
of feature codes for use in selecting at least one network 
features of a local network having a base station, wherein the 5 
mobile phone has a pre-determined means for selecting an 
original set of feature codes, and wherein the original set of 
feature codes is at least partially incompatible with the local 
set of feature codes, the mobile phone comprising: 

a transceiver for receiving a message transmitted from the 1Q 
base station, the message including the local set of 
feature codes, and for transmitting responses and 
requests to the base station; 

a first memory means for storing the original set of feature 
codes; is 

a second memory means for storing the local set of feature 

a processor comprising; 

an input for receiving the message from the transceiver; 
a comparator means for comparing the local set of 2Q 

feature codes with the original set of feature codes; 

and 

if the local set of feature codes is at least partially 
incompatible with the original set of feature codes, 
means for storing the local set of feature codes 2J 
within the second memory means; 

a correlation means for correlating a local feature code 
from the local set of feature codes to correspond an 
original feature code from the original set of feature 
codes in response to a user selection of the original 3Q 
feature code; 

an output for sending the local feature code correspond- 
ing to the at least one network feature to the trans- 
ceiver to transmit to the base station; and 
a user input in communication with the processor for 35 

selecting the original feature code corresponding to the 

at least one network feature. 

19. The mobile phone of claim 18, wherein the message 
is a registration acknowledgment message. 

20. The mobile phone of claim 18, wherein the message 40 
is a Paging Channel Message. 

21. The mobile phone of claim 18, wherein the message 
is a Forward Traffic Channel Message. 

22. The mobile phone of claim 18, wherein the message 

is a Data Burst Message. 4S 

23. A mobile phone with a pre-determined means for 
selecting an original set of feature codes for activating one 
or more network features of a local network responsive to at 
least one of a local set of feature codes, the original set of 
feature codes having at least one original feature code that 50 
is incompatible with the local set of feature codes, the local 
network having a base station, the mobile phone comprising: 

a user input in communication with a processor for 
selecting an original feature code of the original set of 
feature codes corresponding to a desired network fea- 55 
hire of the one or more network features; 

a transceiver for transmitting a request for the selected 
original feature code to the base station and for receiv- 
ing from the base station the local set of feature codes; 
and 60 

a memory means in communication with the processor for 
storing the local set of feature codes, the processor 
including means for correlating the selected original 
feature code to a corresponding local feature code from 
the local set of feature codes and causing the trans- 65 
ceiver to transmit the corresponding local feature code 
for the desired network feature. 
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24. The mobile phone of claim 23, wherein the user input 
comprises a keypad including a "Menu" key and a plurality 
of function-selecting keys, wherein a combination of the 
"Menu" key followed by at least one function-selecting key 
selects an original feature code from a pre-programmed 
menu location in the memory means. 

25. The mobile phone of claim 23, wherein the user input 
comprises a "star" key and a plurality of numeric keys, 
wherein a combination of the "star" key followed by at least 
one numeric key selects an original feature code. 

26. A method for accessing a plurality of network features 
enabled by a first set of feature codes using a mobile station 
having a second set of feature codes corresponding to the 
network features, the first set of feature codes having at least 
one feature code differing from the second set of feature 
codes, the method comprising; 

communicating between a network base station and the 
mobile station to register the mobile station with the 
network base station; 

transmitting the first set of feature codes from the base 
station to the mobile station; 

comparing the first set of feature codes with the second set 
of feature codes; 

if the first set of feature codes is different from the second 
set of feature codes, storing the first set of feature codes 
within a memory of the mobile station; 

selecting a second feature code from the second set of 
feature codes corresponding to a desired network fea- 
ture of the plurality of network features using a user 
input on the mobile station; processing within the 
mobile station the selected second feature code to 
correspond to a first feature code for accessing the 
desired network feature; 

transmitting from the mobile station to the base station the 
first feature code corresponding to the desired network 
feature; and 

if the first set of feature codes includes a new feature code 
for a new network feature that is unavailable in the 
second set of feature codes of the mobile station, 
informing the user of the availability of the new feature 
code, and establishing means for the user to utilize the 
new feature code. 

27. The method of claim 8, wherein the local set of feature 
codes includes an additional feature code for an additional 
network feature that does not correspond to an original 
feature code of the original set of feature codes, further 
comprising the steps of: 

notifying the user of the additional feature code; and 
prompting the user for an acknowledgment of the addi- 
tional feature code. 

28. A mobile phone having means for accessing a new set 
of feature codes for use in selecting one or more network 
features of a local network having a base station, wherein the 
mobile phone has a pre-determined means for selecting an 
original set of feature codes, the mobile phone comprising: 

a transceiver for receiving a message transmitted from the 
base station, the message including the new set of 
feature codes, and for transmitting responses and 
requests to the base station; 

a first memory means for storing the original set of feature 

a second memory means for storing the new set of feature 

codes; 
a processor comprising; 

an input for receiving the message from the transceiver; 
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a comparator means for comparing the new set of feature 

codes with the original set of feature codes; and 
if the new set of feature codes is different from the 
original set of feature codes, means for storing the new 
set of feature codes within the second memory means; 5 
a correlation means for correlating a new feature code 
from the new set of feature codes to correspond an 
original feature code from the original set of feature 
codes in response to a user selection of the original 
feature code; 10 
an output for sending the new feature code corresponding 
to the desired network feature to the transceiver to 
transmit to the base station; 
a means for identifying an additional feature code from j5 
the new set of feature codes that does not correspond to 
an original feature code; and 
notification means for notifying a user of the availability 
of the additional feature code; and 
a user input in communication with the processor for select- 20 
ing the original feature code corresponding to a desired 
network feature. 

29. A mobile phone with a pre-determined means for 
selecting an original set of feature codes for activating one 
or more network features of a local network responsive to at 



least one of a new set of feature codes, the local network 
having a base station, the mobile phone comprising: 

a user input in communication with a processor for 
selecting an original feature code of the original set of 
feature codes corresponding to a desired network fea- 
ture of the one or more network features; 

a transceiver for transmitting a request for the selected 
original feature code to the base station and for receiv- 
ing from the base station the new set of feature codes; 

a memory means in communication with the processor for 
storing the new set of feature codes, the processor 
including means for correlating the selected original 
feature code to a corresponding new feature code from 
the new set of feature codes and causing the transceiver 
to transmit the corresponding new feature code for the 
desired network feature; and 

wherein the new set of feature codes includes at least one 
local code that is unavailable in the original set of 
feature codes, the processor further including means to 
notify the user of the availability of the at least one 
local code. 



